This blog has moved to Medium

Subscribe via email

Dealing with Version Branches

At Delver, like many other places, we use version branches to maintain releases. We have one trunk where everything gets integrated, and when we want to stabalize a release version, we create a version branch and do a ‘code freeze’ on this branch. On the version branch, only bug fixes are committed, and no new features are developed.

This process helps us stabilize versions within a matter of days and proceed quickly from trunk to QA to Production.

A problem we experienced with this process was it was hard to make sure all bugfixes were properly merged to trunk. The commonplace practice is to merge all changes from the version branch to trunk at the end of the release cycle (when the version is “frozen”).

There are at least two problems with this approach:

  • First, it is usually one person who is left the ugly task of doing the merge of all these bugfixes that weren’t previously merged, usually in files he didn’t touch and knows nothing about.
  • Second, if there are bugfixes on the version branch after the version is frozen, what is to guarantee they will reach trunk? The sad answer  is “nothing” – we had several regression bugs because people forgot to merge their bugfixes).

Here is our NewAndImprovedProcess™ (as implemented by our very own Sergey Goncharov):

We setup a TeamCity build that monitors all version branches. It runs nightly, and examines the mergeinfo SVN property on all modified files. If it detects files that were committed to the version branch but weren’t merged to trunk, it fails and send an email to the responsible developer. A little convenience feature we sprinkled in was that if you have a change set that you really don’t want to merge to trunk, you can write in the commit note “[NO MERGE]” and the build will ignore this commit (you can also do a ‘recorded merge’, which is the proper SVN way of doing it, although  adding the commit note is faster in a quick-and-dirty way).


  1. Eli:


    This is a real problem and automating parts of the process can’t hurt. However, I remember two simpler solutions from my IBM days:

    1. The person responsible for said branch has to make sure (after release) that the branch was merged back, by diffing the branch with the trunk and seeing that all bugs are in. This shouldn’t take too long.
    2. When serious bug fixes are made to the release branch, it’s recommended to immediately merge them to trunk. Merging single bug fixes is usually very easy and takes a couple of minutes.

  2. ripper234:


    1. Merge code that 30 people committed from the version branch to trunk can be a daunting task for one person. I prefer delegating and distributing this responsibility to all the devs.
    2. I agree – in general, merging quickly also is easier. The longer you wait, the harder it is to merge, because the odds the code has change increase with time.