SVN repository structure for Drupal projects

Posted by tom on 28th Jul 2008

drupal
svn

SVN repository structure for Drupal projects

I like to keep all my projects under source control, however big or small. It only takes a few minutes to set up and always saves me time in the long run. When I first started working with Drupal, I spent some time thinking about the best way to SVN-ize my drupal projects and, with the help of several other articles and discussions on the topic (specifically an article from Advantage Labs entitled Advantage Labs SVN Repository Structure and a discussion on workhabbit.org, SVN Repository Structure For Drupal Projects) I settled upon the following structure:

drupal
  sites
    6.x
      all
      site1.com
        modules
        themes
        files
      site2.com
      site3.com
    vendor
      drupal-contrib
        modules
          date
            6.x-2.0-beta3
            6.x-2.x-dev-2008-07-21
            6.x-2.x-dev-2008-07-25
        themes
      drupal-core
        5.7
        6.2
        6.3
      fckeditor
        2.6
        2.6.2
      geshi
      phpmailer

So, to break it down a little:

/sites/ - Each site has it's own subdirectory in here.

/sites/all/modules/ - Modules that are used in all sites are pulled in from /drupal/vendor/drupal-contrib/modules with svn:externals. For example:

$svn propedit svn:externals ~/public_html/drupal-6.x/sites/all/modules/

google_analytics    ...drupal-contrib/modules/google_analytics/6.x-1.2
menu_breadcrumb     ...drupal-contrib/modules/menu_breadcrumb/6.x-1.x-dev
custom_breadcrumbs  ...drupal-contrib/modules/custom_breadcrumbs/6.x-1.3
pngfix              ...drupal-contrib/modules/pngfix/6.x-1.0
pathfilter          ...drupal-contrib/modules/pathfilter/6.x-1.0
...

Note: I cut the urls short so they would diplay properly in this article.

/sites/site1.com/modules - Site specific modules are again pulled in from /drupal/vendor/drupal-contrib/modules with svn:externals.
/vendor/ - Vendor sources are stored here.
/vendor/drupal-contrib/modules - Whenever I download a drupal module, I extract it into the appropriate place in this directory. I keep copies of every single version of a module that I have used, including development snapshots.
/vendor/drupal-core - Each release of drupal gets stored in here. I remove the /sites directory and the robots.txt file first (I use the robotstxt module to dynamically create a unique robots.txt file for each site).

I only need to run two commands to install the whole setup on a new server:

$svn checkout /drupal/vendor/drupal-core/6.3 drupal
$svn checkout /drupal/sites/6.x drupal/sites

When a new Drupal core is released, I download it, remove the sites directory and robots.txt file and commit it to my repo. Then, I simply run svn switch in my working copy and all sites benefit from the change.

When a new version of a module is released, I download it and commit it to my repository in a suitable location. Then I run svn propedit svn:externals on each of the modules directories that I want to update (or on /sites/all/modules if I want to update for all sites). If the new version of the module causes a problem, I simply change the svn:externals property to point to the old version and svn update again.

I'm sure it could be done better, but it works pretty well for my needs.

Similar articles on this site

Shrop
31st Aug 2008, 10:33am

This is very similar to how I work except I am still committing the full drupal project. I do maintain vendor releases like you are doing. How do you deal with databases? I am currently tagging releases for prod with the database and files that went live at release time. The other question is if you upgrade a module and then have to switch back, I guess you may have to manually restore the module's schema changes if there were any?

Very nice post..thanks

Thanks!
Shrop

tom
4th Sep 2008, 8:45am

Databases is the one thing which I don't think I have covered particularly well. Like you, I dump my database, store it with my site files and tag it when I release. I use the backup_migrate module to do this since it lets me easily exclude all the cache tables. I regularly sync the database from prod to dev to ensure I have a recent copy on my local machine too. I'd love to hear about a better way...

re. modules - if you uninstall a module correctly, it will actually take care of schema migrations for you (assuming the module author has dome things correctly). It's pretty easy to check - just look in the modules .install file and make sure that the modulename_install() and modulename_uninstall() hooks do the reverse of each other.

Shrop
4th Sep 2008, 6:54pm

Thanks for the tip on the backup_migrate module. I will check it out.

Also, this just came out in the last day: http://acquia.com/blog/drupal-cli-utils May be useful for what we do with Drupal sysadmin.

Good point on the modules update.php hooks in the module's install file. Where this might get hairy is if the module migrates data to a new field and removes the old field. Things like that may not be covered by hook_uninstall(). You are right in the fact that you can check the install file and it probably isn't a big deal most of the time.

Thanks for sharing!
Mark