Branching and tagging in Subversion
Facts - Other software technologies
Wednesday, 18 January 2012 20:14

This note is for subversion version 1.6.

Branching and tagging in subversion (and Perforce) is equivalent to associating an existing file or directory to a different path in the subversion repository. Internally the server does not really copy the files, instead it makes a link when you create the tag. When code in the branch is modified it does the internal copying.

There are two types of code bases. In many code bases there are a couple of big releases per year on the HEAD revision. In addition there are bug fixes on most releases that have been put into production. For these kind of projects you could tag the whole code base at each release. So your directory structure on the subversion server would look like this:

trunk
  source
  configuration
branches
  release1
    source
    configuration
  release2
    source
    configuration

In the example above the main branch is in directory trunk containing two subdirectories, source and configuration. For each of the two releases the subversion repository contains a branch, release1 and release2, with the same subdirectories.

Some code bases don't release just a few times a year, instead they have many small releases. Suppose your code base consists of six parts:

  • code for the billing department
  • code for the delivery department
  • code for the sales department
  • in subdirectory common0 code used in the billing, delivery and sales subdirectory
  • in subdirectory common1 code used in the billing and delivery subdirectories but not in the sales directory
  • in subdirectory common2 code used in the delivery and sales subdirectories but not in the billing directory

Here is the main branch of such a subversion repository:

trunk
  source
    billing
    common0
    common1
    common2
    delivery
    sales
  configuration
    billing
    common0
    common1
    common2
    delivery
    sales

Suppose a small project modifies the billing subdirectory to use a new pricing structure, let's call this project pricing2012. After putting this project into production you may want to tag the release like this:

branches
  pricing2012
    source
      billing
      common0
      common1
    configuration
      billing
      common0
      common1

With this kind of branching all released code can be easily checked out later. Instead of making a branch with a part of the code in the trunk we could have made a branch containing all code in the trunk. Unfortunately this can lead to an excessive check out time if the code base in the main branch is very large.

Obviously the branch contains the billing subdirectories. Note that the branch does not contain the delivery, sales and the common2 subdirectories since this part of the code has not been modified within the project. Subsequent bug fixes won't need to touch these three subdirectories either. The branch contains the common0 and common1 subdirectories as well. Although the code in common0 and common1 might not have been modified we can not guarantee that bug fixes won't need to modify them in future. In addition the code in the first two common subdirectories in the trunk directory might change after the billing release. So putting the first two common subdirectories in the branch makes it a lot easier to check out, fix and test the code later.

This approach seems to be straightforward. Nevertheless not all projects with many small releases do this kind of consequent branching. Especially when the common code is located in many different subdirectories, it takes a lot of discipline to include the common code that might be modified in future bug fixes in the branch.