svnTalk.com

If I had to pick my two favorite website applications my decision would be easy. Subversion, of course, hence the svnTalk.com website and the other would be the content management system known as Drupal. Put them both together and it is like chocolate and peanut butter working together in a delicious mix of flavors, living in sweet harmony.

I actually have two separate, multi-site Drupal installations that currently utilize the subversion versioning system and each one is set up just a little differently. I have yet to decide which one I prefer because each has its own set of pros and cons.

Before I get into the different installation lets talk a little about how subversion works with Drupal. It’s pretty straight forward really, you create a repository which is the “brain” of the subversion system. The repository is the location that all users, or clients, use to connect their satellite checkouts, or very own local copy of the repository. I am using https as my connectivity to the repository which pretty much gives me access to my Drupal repository from anywhere in the world, not that I do that much traveling. The checkouts then have the ability to edit, add and delete files, folders and code inside the Drupal repository. Subversion keeps track of all the changes made, as well as who made them. This is glorious! When a client makes a change to some information on their local checkout (themes, code, images, scripts, etc..) they commit those changes to the repository. And now every client has access to those changes.

One very important client is the web root client. This client is really no different that any other client except it really doesn't do any work … oh and he is not a human, which most of you are (spiders and bots excluded). He just sits there and collects all of the changes that all the working clients are making. His job is to show you, the web reader, everything you see here in your web browser. He keeps updated by the using a post-commit hook that is triggered when a user commits code changes. Remember how I said that the repository is there for each client to access? Well, by doing an update on the client side, all repository changes are propagated to that client, including the web root client.

Ok, hopefully the above wasn’t too confusing and now I can move on to the two different multi-site Drupal installations using Subverison. First off, the core Drupal files are really no different between the two. They both have a repository, and they are both versioned the same. The difference lies in the way that the sites folders are build. In my first installation, the core Drupal files (call them the out of the box files) are build in their own subversion repository. Each separate site folder has its own repository, it’s own post-commit script and is completely separate from the base Drupal core repository.

This is a good choice when you have multiple users developing different sites within the same Drupal installation all at the same time. The biggest reason is that when a client commits a change to a file, theme, or site module, the post commit script will run only on that single sites folder.

The second installation is recursively versioned. All files and folders, including the sites in the sites folder are all in the same repository. I still have the ability to allow client checkouts only access their specific sites folder, buy doing folder level authentication, but when the post-commit hook is called, the entire web root client has the update done to it. I have not had a chance to fully evaluate the problems with doing this configuration but for the multi-sites that I currently mess around with, svnTalk.com, improving-home.com, locksofstyle.com and renbp.com this works just fine for me.

The last issues that I have not been able to fully figure out is how Drupal has its own way of dealing with is user, or shall I say, Drupal upload files. These files become just un-versioned entities that hang out in the files folder of the web root directory. I wonder if there is a way that Drupal, after an upload could do a “svn add”, and a “svn commit” to that newly uploaded file. That would be nice.