My Subversion Workflow

Some time ago, I read an article by web developer Yongfook titled 10 Dirty Little Web Development Tricks. A quick Google search will return several results linking to this article but unfortunately – and, as far as I can tell – the page no longer exists. In any case, there was one “dirty little trick” that caught my attention more than all others, and that was to use Subversion instead of uploading files via (S)FTP for managing production releases. Now, I don’t quite remember Yongfook’s process, so I won’t attempt to reconstruct it; however, I can share my own setup, which is still fresh in my memory.

Working Locally

The first thing I do is create a SVN repository using the SVN Book’s recommended repository layout.

branches/
tags/
trunk/

After creating my repository, I svn import any work that I may already have completed into the trunk. I should note that I do not version control the system that powers my site (currently Habari) but rather the directory containing all design related documents (i.e. themes).

$ svn import [themes] [repository/trunk] -m "Initial import."

I like to work locally for several reasons, the most important one being the ability to work from anywhere without the need for a network connection. So, I setup my site using MAMP and proceed to svn checkout a copy of my repository.

$ svn co [repository/trunk] [local path]

From this point on, I work on my local server, committing changes in to the repository as often as I have to.

Stage, Tag, and Release

Once I’m ready for the world to see what I have been working on, I setup a staging instance of the site on my production server. I svn checkout a copy of the repository and keep any Subversion data files from prying eyes by writing a redirect rule on my .htaccess file. Note that a svn checkout is only needed once; after the initial checkout, a svn update is all that’s needed.

$ svn co [repository/trunk] [staging path]
RewriteRule \.svn / [F,L]

If everything on the staging instance looks right, I svn tag the trunk in order to make releases systematic. And, proceed to svn export the tagged released onto production.

$ svn copy [trunk] [tags/release #] -m "Tagging release."
$ svn export [tags/release #] [production]

Why svn export? Because it removes any SVN data files, which are no longer needed on production.

Benefits, Notes, and Thank Yous

As I noted earlier, working locally means working from anywhere, regardless of an internet connection. Furthermore, setting up an staging instance of your site can help you detect problems most likely to occur on production. And, finally tagging your releases will most definitely make the process of keeping track of and reverting changes, if necessary, effortless.

During the process of writing this article, I stumbled upon a great article that touches on many of the same issues that I have covered. It is definitely worth the read, especially if you are not very familiar with Subversion.

Finally, I have to give a shout out to Greg Chiasson who wrote the redirect rule for me in less than 5 seconds, as well as, Paul Jones and Christian Dailey who unknowingly contributed to my setup and consequently this post.