How and to create efficient Branches using Subversion

To a lot of people Branching is a dark art which should be avoided at all costs. This makes me sad since its such a great feature of most version control systems. A branch is normally a copy of the trunk which is totally isolated from the Trunk. Creating a Branch allows you to create parallel or more development streams.

Even though Branches aren’t a dark art, they are a little more complicated than most things in version control. This shouldn’t put you off using them, as they will save you time in the long run. But you should take time to organise them and create a structured naming convention.

Below is a diagram of a single Branch being created from the trunk. Have a quick look at it, then I’ll describe the process in detail.

Firstly we need to create an anchor point to remind us when in the repositories history the branch was created. This will help us in the future if we are unsure what patches need to be applied.

To do this we create a Tag from the Trunk. I’m going to pretend we’re at the start of this projects life. So I have created the Tag as 1.0.0, remember to create a Tag just use the copy command in subversion and place the copy in the Tags directory in the repository.

Now we have a fixed position to play with we can create our Branch. This is a copy from the Tag we have just created (1.0.0), but this time placed in the Branches folder of the repository. We name our Branch with a reference to where it was created, this is where the Tag comes in. Here I will name the Branch 1.0.0_B1. Where as Tags are normally read only, Branches are not. We use branches to allow multiple development streams to work on the same pieces of code.

Heres an example of when to use a Branch.

Lets say you wanted to redevelop your database access layer of code. This may take a significant length of time. By which I mean that you might need to bug fix your existing code before the new code is available to use. This is when you would use a Branch. This allows you to seperate your new code, while allowing you to maintain your Trunk.

Once you are happy that your branch code is ready to be used in anger you need to get it back into the trunk. This can be done in two ways, you can checkout both the Branch and the Trunk and use a diff tool to merge the changes. The other way is to create a patch (I’ll be explaining patches in a future article).

Once the code is in the Trunk and tested, commit the changes and create another Tag. This will be a reference in the future of when you committed these changes. In my example I’ve named the Tag 1.1.0 to indicate a minor change to the code base.

Now for a more complicated example, in less detail now since I’m sure you understand the basic ideas.

1 ) Create Tags/1.0.0

2 ) Create Branch/1.0.0_B1

Meanwhile a bug fix is made to the Trunk.

3 ) Create Tags/1.0.1

4 ) Create Branches/1.0.1_B1

5 ) Merge bug fix from Trunk to Branches/1.0.0_B1

Work is done on both Branches. Branch 1.0.0_B1 is ready to commit merge to the Trunk first.

6 ) Merge 1.0.0_B1 to Trunk

7 ) Create Tags/1.1.0

The 2nd Branch is now out of line with the Trunk.

8 ) Merge Trunk to Branch 1.0.1_B1

Development on the 2nd Branch has now finished and is ready to be committed to the Trunk.

9 ) Merge Branch 1.0.1_B1 to Trunk

10 ) Create Tags/1.2.0

Fin

Using a clear naming convention allows you to understand how and when you need to make merges to where. Once you are finished with the Branches you can delete them, or keep them if you are interested in the individual revision history.