Subversion comes to ZiTYZEN.dk

Today I completed the setup of the version control system that I initiated more than a month ago. It's not that it's hard to do, it's just that I needed some time to pull myself together and get the job done. It's one of those tasks that you don't really see the benefit of today, but the day catastrophe strikes you hate yourself for an entire month. So it's basically an insurance (and a really cheap one, because it's really easy to setup and maintain).

I chose to use SVN (subversion), mainly because we've used CVS in university and was a little tired of the missing functionality of not being able to delete directories and not being able to rename files.

The installation is really basic, you type "apt-get subversion", and you're more or less done. The you setup a repository first by creating the directory "mkdir /home/zityzen/repos/", then you create the repository "svnadmin create /home/zityzen/repos/". Now you want to import the files you already have into the repository, which is done using this "svn import /home/zityzen/repos/ file:///usr/local/svn/repos/some/project \ -m "Initial import"", were some/project is the location of the existing files.

Then there is the trouble of how to structure the layout of the repository, I've chosen a fairly standard way, in which there is a trunk (corresponding to the test-server) and a number of releases (the latest release corresponds to the running version of the production-server). This implies that whenever something is committed it's done to the trunk and whenever a new release is required the export function of SVN is used to create a new release. Note that the old releases are not deleted, they are needed in order to perform roll-back operations. The export command looks like this: "svn export /home/zityzen/checkouts/trunk /home/zityzen/checkouts/release/2008-11-07--1", this denoted that this is the first release on the 7th of November 2008. I've also create a little bash-script that figures out the name and does all the copying for me, nice and easy... I also used another of the features of SVN, hooks. These are scripts run after e.g. commit, the hook can then be used to copy the content of the trunk over to the running version of the test-server, such that it's kept up-to-date whenever something is committed.

Furthermore I've created the real insurance namely the roll-back script, which deletes the latest release and replaces the running production-code with that of the second-latest release, again: nice and easy.

Now you might argue: you don't need SVN to perform that, you can just run those bash-scripts, they will still perform the same operations and be equally insuring and useful. Partially true, I don't really need SVN, but it's nice to have this added insurance on top of the multiple releases, furthermore using SVN forces me to use those scripts, which I otherwise could forget. Additionally having SVN is a benefit when you work in teams, and although we're not a large team yet, SVN makes the job of sharing files much easier.