You are here

Drupal, Subversion, CVS, and Piston

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 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 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 ./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 ./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 svn commit.

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 CVS and .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.

Add new comment