Tin Isles

I’ve finally taken out the time to properly learn about the subversion “trunk, branches, and tags” structure. So while its fresh in my head I thought I’d blog about a common scenario with an extremely contrived example. New to Subversion? Here’s the links that got me started:

1. Version Control with Subversion – a free book about Subversion.
2. VisualSVN Server – a simple to use (and free!) Subverion server for Windows.
3. CollabNet Subversion Downloads – a command line server and client.
4. TortoiseSVN – a Subversion client, implemented as a windows shell extension.

This is the scenario: You’ve deployed an application to production. A few weeks later development work is continuing on the source tree, when someone finds a bug in production. The development code isn’t ready for production, and hasn’t been tested. So we want to pull out the production version of the source code, apply a bugfix, reapply the fix to the development tree, and roll out the updated production build. This is a very common scenario outlined in the “Version Control with Subversion” book here: Release Branches.

The fix? In short terms Subversion makes this possible with the following steps. Once code is ready for a production deploy we create a production branch “/TurtlesApp/branches/Production”. Any production bugfixes can be carried out in this location and, with the help of Subversion, merged back into the developement tree “/TurtlesApp/trunk”

Step by step: Here’s the extremely contrived application ready to go to production. We’ve created a simple application which reads in an XML file, populates a collection of business objects, and binds this to a GridView.

View Code

Ready for production – create a branch:

Now we have a something that looks like this in the repository:

Work continues in the development trunk, with new features are being added.

View Code

But in production someone has discovered a bug. They’ve attempted to add this line to the XML file:

<Turtle Name="Splinter"/>

The code is crashing out attempting to read the ‘null’ weapon. The development tree hasn’t been tested, and isn’t ready for production (contrived, I tell you!). So the changes can be made in the ‘Production’ branch and merged back into the trunk.

Let’s say we are doing our dev on the “C:\VS2008\TurtlesApp\trunk” folder. We’ve got IIS vdirs pointing at this app, and a number of build scripts expect things to be in this location. This is where the svn switch command comes in handy. Using this command we can replace our code in “C:\VS2008\TurtlesApp\trunk” with the production branch.

The bugfix is a simple test for null:

turtle.Name = (node.Attributes["Name"] != null) ? node.Attributes["Name"].Value : null;
turtle.Weapon = (node.Attributes["Weapon"] != null) ? node.Attributes["Weapon"].Value : null;

Let’s commit this to the “Production” branch, and we are ready to build and deploy.

The bug still exists in our development trunk. Subversion can merge the changes we’ve made in production back into development. In the real world a bugfix could impact any number of source files. I start the merge by first switching my directory back to the trunk, getting an update of the source – always a good convention if you are about change a bunch of files – then do the merge.

So what does the Turtle.cs file look like now with the changes merged in…

Turtle turtle = new Turtle();
turtle.Name = (node.Attributes["Name"] != null) ? node.Attributes["Name"].Value : null;
turtle.Weapon = (node.Attributes["Weapon"] != null) ? node.Attributes["Weapon"].Value : null;
turtle.Nickname = node.Attributes["Nickname"].Value;
turtle.Colour = node.Attributes["Colour"].Value;
results.Add(turtle);

Very cool! Subversion has automatically added our production changes to the development branch!