Posted by jax on February 12, 2007 at 2:51pm
I was wondering how you guys organize your svn/cvs repository for your drupal installations. Where do you put the contrib modules (if you keep them in your repository)? Do you keep the module code or do you keep only the .tar.gz's? Where do you put your themes/modules? Etc.
The structure I was thinking to implement would be:
/reponame/trunk/themes/mytheme/
/reponame/trunk/modules/mymodule/
/reponame/trunk/vendors/drupal.4.tgz.
/reponame/trunk/vendors/contrib_module.tgzThis way you know which contrib modules are used and which ones are yours. The themes and modules you created can be checked out in
drupal/sites/development.tld when you develop and drupal/sites/example.com for production. I've thought about this a couple of times and every time I come up with another solution.
How do you manage/structure your repository?
Comments
I've also posted this
I've also posted this question on the regular drupal forums:
http://drupal.org/node/118936
What do you think about that approach? Feel free to submit your's. I need to organize this at work so I would like to make an informed decision.
Depends on needs
Your model works for a single website. For Drupal multisite, you want a top level sites directory that is versioned separately from the core multisite code. i.e. keep the stuff that is going to rev more often (sites) from the multisite code that will change much less rapidly.
Development cycle
The real question is, in my opinion, and in the way this question affects me personally in a practical sense, is, what is going to be your production cycle?
Are you going to be doing modules of your own?
Anyway, what works for me is the following (first time):
1) Get a site going on my development box.
2) Put third party modules in ./sites/all/modules/
3) Download or Copy the theme I am going to use into ./sites/all/themes/mytheme with its own name
4) Get it like I want it (configuration, some initial data).
5) Make a ./sites/all/backup directory and place a mysql script there;
for example:
mysqldump -u drupaluser -p dbasename > mysite.sql6) Now having my entire site, its uploaded files and the database complete, I initially import (later on after major changes commit) the whole kit-and-kaboodle into SVN (which does a better job than CVS on binary files, that is it feebly attempts to do something about versioning them). The repository can be anywhere.
7) I then go to my hosting, and on the command line (ssh required, or else try to do the equivalent with some sort of file manager that hosting companies usually provide, with unpacking facilities hopefully), check out into the root directory or wherever it is I want to put my site, the whole kit and kaboodle.
8) I go into the backup directory and stash the .sql dump into a database I have already provided, with its own private user which has full rights to that database and nothing else.
mysql -u drupaluser -p dbasename < mysite.sql9)I go into ./sites/default/settings.php and fix the database url (user and password).
10) I adjust write permissions on the files directory if necessary.
11) I enjoy my site.
From then on, I do commits from my development machine (NOW with the exception of the SQL backup and the settings.php file) to the SVN repository, and then do svn update in my production Drupal root.
I may want to commit the SQL backup from the production site.
I may want to have the production site checkout and update its stuff from a TAG branch (or a release tag in CVS) while the development box has its own branch (kind of HEAD branch), but that would be a more advanced discussion.
CAVEAT for image files: This assumes that images have the same path relative to Drupal root.
CAVEAT for .htaccess: Make sure that at all times, the Drupal root .htaccess file makes it through the process and is always present in your Drupal root directory.
CAVEAT for robots.txt: If you development box is on some publicly accessible hosting, edit your robots.txt so that you don't get googleized prematurely. Google robots.txt to find out how, it's easy.
Under no circumstances work with an TGZ packed file in your verson control, it doesn't give you the granularity over files you need for version control.
(the above all just my own opinion, of course, what works for me).
Victor Kane
http://awebfactory.com.ar
Victor Kane
http://awebfactory.com
what is the life cycle for coding CCK nodes, views, etc?
Can you help me with some clarification? In your approach, where do you do development work such as creating a new CCK type, coding a computed field, etc? My default is to treat my drupal work as much like a software product development work as possible - which means a life cycle that includes
- code in development environment
- deploy to a test environment
- deploy to a production environment
Typically, I assume that I can seperate "development data" (e.g. default data in the database, code, etc.) and "user data" (data generated by a user via the product), so that when I update a production site, I can leave the user data intact (or possibly migrate it ala rails) and seperately deploy new "development data".
However, when I need to code up some new CCK node, some views, some custom computed field, etc. in Drupal - I'm unable to seperate out the "development data" from the "user data". As a result, I'm left with
- code in development environment
- deploy (what can be deployed) to a test/production environment
- re-code what wasn't deployable (e.g. CCK node, views) in the test or production environment
That last step is risky since I don't have an automated way to do it, I re-introduce the risk of untested coding.
Am I missing something? Is there a (good) way to extract data (e.g. CCK node definition) and treat it as a "development data" and apply it to a production site?
thanks
Steve
Well, both views and cck
Well, both views and cck have an import/export facility which effectively reduces views and cck definitions to text, and hence something conveniently placed under version control.
The downside is that a certain redundancy is created (content in the database, and under version control in a directory somewhere). But who cares, in a way, since the main thing is the ability to version cck and views code as text.
Victor Kane
http://awebfactory.com.ar
Victor Kane
http://awebfactory.com