When I decided to start this blog, I decided to maintain the site almost exclusively in subversion. Having worked with this for a few weeks, I've found it to be much easier than the "traditional" method of setting up Drupal.
I'm not the only one to do this. Agaric Design's approach was helpful but left me scratching my head.
To do this, first, I created an area for Drupal in the vendor directory of my repository:
svn mkdir drupal/5
I use a vendor directory because I have some projects that, while unrelated, rely on the same software. I could use a vendor branch in each project but I decided that more overhead than I wanted. (If I had a single repository per project, vendor branches would be fine. Instead, since I have multiple projects in a repository, a separate vendor directory makes more sense.)
(For those wondering, the 5 denotes the version of Drupal. Versions 5 and 6 are incompatible so it's necessary to separate the Drural code and modules by major version.)
Before I can import Drupal core into my repository, I need to check it out from Drupal's CVS. So in the directory I created and, following the directions, I run:
cvs -z6 -d:pserver:anonymous:firstname.lastname@example.org:/cvs/drupal co -r DRUPAL-5--14 drupal
Now, to add it to the repository:
svn add drupal svn commit
To import a module, the steps are mostly the same but using the different CVS parameters: (the globalredirect module used as an example)
cvs -z6 -d:pserver:anonymous:email@example.com:/cvs/drupal-contrib checkout -r DRUPAL-5--1-4 -d globalredirect contributions/modules/globalredirect svn add globalredirect svn commit
Now, to add this into the site, create a repository for the site. I use 'web' as the main directory of the site and I want to install Drupal in that directory. So in the repository, I run:
svn update piston import http://svn.ithiriel.com/svn/vendor/drupal/5/drupal ./web
Piston is a tool that synchronizes including code from other repositories or locations. It works like
svn:externals but allows for local modifications and tracking those. This is useful since each Drupal site has different configuration files.
Piston requires the local directory to be at the latest revision. In almost all cases, this requires running
svn update before running Piston.
To install a module, say the globalredirect module from before, I go to
web/sites/all/modules and check it out in the same fashion:
svn update piston import http://svn.ithiriel.com/svn/vendor/drupal/5/globalredirect ./globalredirect
This may seem a lot of work to do at first but I'm pretty sure it pays off the next time you need to update the site.
Since I first started work on the site, Drupal 5.15 was released and a new version of the globalredirect module was released. Both of these needed to be updated.
To update the local copy of the original Drupal source, I go back to the directories created before. In
/vendor/drupal/5/drupal, I run:
cvs update -r DRUPAL-5-15 -dP
It's necessary to see if any files have been added or deleted.
svn status will tell you if there are any. I add or delete as necessary. When the status checks out, I commit it with
Back in the repository for the website, I go to the directory above the
web directory and run:
svn update piston update web svn commit
Now the upgrade for Drupal core is done. All that's left to do is run the update script. All of that done with very little fuss.
To update the globalredirect module, I go to
/vendor/drupal/5/globalredirect and run:
cvs update -r DRUPAL-5--1-5 -dP
As for the core, I see if any files have been added or deleted. When everything is ready, I commit the revision.
To update the module on the site, I go to
web/sites/all/modules in the site's repository and run:
svn update piston update globalredirect svn commit
As before, I run the update script and it's done.
Upgrading modules isn't such a big deal but upgrading the core tends to feel like a pain. Being able to do it with a set of easy commands makes the process much more tolerable.
There are two issues with this method though.
The first is that when checking directly out of the Drupal CVS, the version numbers will not be set correctly. If using Drupal 6 or the update status module for Drupal 5, the CVS deploy module is required so the version numbers can be determined correctly.
The second is that this process exposes the
.svn directories to the public. However, I can deny access to these with Apache with these directives:
RedirectMatch 404 /\\.svn(/|$) RedirectMatch 404 /CVS(/|$)
(For those following along, if you do not have access to the Apache configuration file, the documentation for
RedirectMatch indicates that it can be placed in
.htaccess files. I haven't tried it so I make no guarantees.)
Edit: Made some grammatical and wording changes because I wasn't happy with the originals.