Subversion Branch Management


If you’re just starting out with SVN, chances are you use the “just-throw-everything-on-trunk” method which will eventually lead to some, “Who broke staging again!?!?!” moments. I was introduced to the world of SVN branching via a large code rewrite effecting… pretty much our entire codebase.

Through that experience, I realized the benefits (and the hardships) of maintaining your own branch of Trunk. One of the things I love about our culture here is that we “kill the sacred cow” meaning we don’t do things just “because we’ve always done it that way.” With that in mind, we decided to have each developer setup their own project branch instead of just committing to Trunk. The benefits have been huge. We now have a Trunk the entire team can rely on. When rolling out new code, that confidence goes a long way and avoids quite a few rabbit holes trying to determine if your code changes are the problem or if someone else is half-way through a project and their code is the culprit.

After learning things the hard way, I’ve come to really appreciate Chapter 4 of the book Version Control with Subversion. If you’re not using branches and you have more than a couple people on your team, you should be using branches. If you are using branches, this chapter is a must read. It will take about an hour or so to get through, but it will save you a lot of trouble down the road.

Unless you’re using SVN version 1.5, I recommend using a wiki page or excel file to keep track of your revision numbers. This can be really helpful as you start rolling code out to your development servers, merging with release and updating your live servers. Knowing what you’ve merged and what’s been updated on which server really saves time, especially during ongoing development while rolling out bug fixes to existing versions. Below are a couple examples using Confluence and Excel:

Take it from someone who has been there, done that, got the t-shirt… branch management can be great if you do it correctly and keep track of your revision numbers during the process.

This isn’t a perfect process, but it’s the best one we’ve come up with.  If you’ve found a better way, leave a comment and start the conversation.

2 Responses to “Subversion Branch Management”

  1. Importing a SVN repository from one server to another one Says:

    […] Why you should use branches with SVN : […]

  2. Matt Muschol Says:

    Branches have lots of benefits, and in practice you will want separate branches for the ongoing development stream, individual activities (i.e. features or bug fixes being developed) as well as maintenance streams for older releases.

    This is very hard to manage through a wiki page (though we managed ours through a wiki page for years, with mixed results). In particular keeping track of what has and hasn’t been merged can be a nightmare (e.g. has the latest hotfix for release 3.1 been merged into the maintenance stream for 3.2 as well as the 4.0 development stream?).

    In the end we developed our own web-based tool to address this problem, initially to scratch our own itch but eventually we realised that others were facing the same problem.

    AgileSCM has since matured into a recognised solution for the management of Subversion branches and now supports Git and Mercurial and provides integrations into change management systems such as Jira, ClearQuest and Trac.

    Have a look at for more information.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: