Branching Options for Development

Branching and merging is a contentious issue for the Subversion community, with even the most experienced Subversion users sometimes needing extra guidance on how best to manage their branches. In our latest webinar, Michael Lester, WANdisco’s Director of Training, provided an introduction to branching and merging which ranged from the basic, ‘what is a branch?’ question, to the different development models open to Subversion users, and advice on managing deleted branches.

Essentially, a branch is a line of development that exists independently of another line. Branches allow developers to work on code independently of the work going on in the trunk. No changes made within a branch are seen by people working in the trunk, or in any other branches. There’s no real limit on the number of branches that can be created, but there are some general development models for branching that Michael addressed in the webinar:

1) “Branching Nothing” Development Model

In this model, all of the development is done within the trunk. In ideal circumstances, all of the checkouts and commits will be in line, and no-one will check out the same thing at the same time, but it’s likely there will eventually be a situation where multiple people checkout the same code simultaneously, and then it becomes a race to see who can make their commit first. The second person to make their commit will receive a message alerting them that their commit has failed, and that they must update their working copy.

‘Updating the working copy’ takes the differences between what was checked out and edited, and what the other person has modified, and applies it to the working files. In the best case scenario, this is a straightforward update, but in some cases it can create a conflict situation.

The branching nothing model can create ‘update hesitation,’ where the developers are aware that performing a commit could force them to go back and deal with other peoples’ changes – a potentially time-consuming and annoying process! – which encourages them to wait until the last minute to make their commit. The branching nothing development model tends to get more complicated, the more people who are working on the same code, at the same time.

2) “Branch Everything” Development Model

With this development model, every change within a project is given its own branch; either a ‘bug branch’ or an ‘enhancement branch.’ People are assigned to work on a particular branch, and these branches are then merged into the trunk. This has a number of advantages:

  • All work is isolated. You don’t have to worry about other changes interfering with yours until the merge happens.
  • All work is scheduled. There is a defined branch for everything that needs to be worked on.
  • All work is branched from a stable trunk revision.
  • Small, independent merges mean it’s usually easier to resolve changes.

However, there are also some disadvantages to this development model:

  • Lots of branches.
  • Lots of merges.
  • A lot of overhead for some very straightforward fixes, e.g the misspelling of a word, or a column heading not being centered.

3) “Branch Big Things” Development Model

With this development model, every task is divided into one of two categories:

  • A small development effort – worked on directly in the trunk, with no branching or merging required!
  • A big development effort – tasks such as a complicated bug or enhancement are given their own branch.

This categorisation is based on:

  • Relationship to other bugs / enhancements – is the change likely to impact any other code?
  • How much testing is required? – some changes may require virtually no testing (e.g correcting a misspelt word) but other times you will literally have to do system-level testing to ensure the changes haven’t had any unforeseen negative effects.
  • How long will the bug/enhancement take?

Deleting Branches & Finding Deleted Branches

Regardless of whether you branch everything, or follow the ‘branch big things’ development model, if you’re going to branch, then at some point you’ll have to delete some of the old branches. Deleting branches is simply a matter of:

1) Go to the repo browser.
2) Right click on the branch you want to delete.
3) Select the delete command.

Remember that when you delete a branch, it gets deleted from the revision folder but not from the repository. You can always go back to an earlier revision to see how the branch looked, and have the option of exporting the code from the deleted branch, or recovering the branch and recreating it in a later revision.

To make it easier to locate a deleted branch, it is a often a good idea to write something in the log message upon deleting that branch. Another good idea, is to create a ‘deleted branch’ folder, where you can store branches that you no longer need.

Need more advice on branching and merging? The full webinar is available for replay now. Our next webinar, ‘uberSVN: Access Control Management’ will show you how to quickly setup access control for Subversion users and how to easily create repository access rules, allocate users to teams, and monitor team activities. The webinar will take place on October 27th, 2011.

0 Responses to “Branching Options for Development”


  • No Comments

Leave a Reply