Guide And Best Practices For Subversion Branching

Since switching to Subversion for version control about two years ago at work, there have always been questions about best practices here and there which were certainly debatable. One of the last long discussions/e-mail threads we had about Subversion was about when to branch, when to stay on trunk, etc. Ned Batchelder wrote a great introduction to branching which you can check-out here.

Using a branch is always more involved than using the trunk, so the trunk should be used by the majority, and the branch should belong to the minority. Subversion is easier than other source control systems in this regard, but the rule still holds: when trying to decide what goes on the trunk and what goes on the branch, put the code that most developers want on the trunk, and put the minority on the branch.

I think one not-immediately-obvious thing to think about when branching is that none of your incremental changes to the branch will show-up in the trunk revision once you’ve merged the branch back into trunk. Instead, you only get the revision where the changes were merged back into trunk. Being that we link revisions with tickets and tasks, it presented a difficult problem to track down changes because people were using branches way too often. For the most part, we now follow the basic rule that you should only create new branches while doing some major changes to existing implementations, or interface changes, while most everything else such as maintenance, new features, and bug-fix type items belong in trunk.

7 Responses to "Guide And Best Practices For Subversion Branching"

By Spike October 30, 2006 - 1:56 pm

There are many ways to approach branching and use it heavily to the benefit of your projects. I have used the flying fish approach on several projects and found that it removes some problems common to most revision control systems. Most notably, the ability of each developer to tag, track and commit on their own branch without worrying about how it will affect others. Merging becomes a more involved and complex process, but the benefits can outweigh that; particularly if you are working with a distributed development team who aren’t always within easy access if something is wrong with the code they committed the night before.

There’s a good section in the “Open source Development with CVS” book dedicated to the discussion of branching. It includes a good description of flying fish and a couple of other approaches. Although the book is written for CVS, the branching chapters apply equally to Subversion.

Here’s a link to save you the time of googling for it: http://computing.ee.ethz.ch/se.....html#SEC84

By Brandon Harper October 30, 2006 - 2:54 pm

Thanks for the link Spike, I hadn’t seen that before (especially being a VSS convert).

As for a bit of irony, we actually started off doing the “Flying Fish” method of branching listed on that site and found it very troublesome because of all of the commits occurring in many different places, as well as not being able to see the full, incremental history in trunk.

I suppose with as with all things technology related, the right answer starts off with “it depends”; I thought I’d just pass on something I thought was good as well as some personal experiences and observations.

By Spike October 30, 2006 - 10:41 pm

Yeah, that’s in line with my experience, in some cases it causes more problems than it solves, but for distributed development, especially where the project has different teams that work semi-autonomously, it can be very useful which is why I mentioned it.

By Pete August 18, 2009 - 2:55 am

In my experience separate branches for major pieces of work cause problems at merge time. We have had different projects working on different branches all scheduled to leave at the same time. The problem comes when you merge, the first merge is typically painless but the last one is horrendous, what’s more is the branches themselves become stale and the only visibility you have is at integration. This can however be mitigated with SVN as is nicely handles merges from trunk to branch and ultimately back again.

By Best Practice Visual Studio with SVN, VCS and SCM « Kevin Steffer October 12, 2009 - 11:21 am

[...] http://devnulled.com/content/2.....branching/ [...]

By KD Web Dev: Subversion Best Practices December 8, 2009 - 7:37 pm

[...] http://brajeshwar.com/2007/sub.....ick-notes/ http://devnulled.com/content/2.....branching/ http://www.karlkatzke.com/best.....ubversion/ [...]

By Rob March 2, 2011 - 12:14 pm

I think when it comes to branches there should be some basic decisions made so that it doesn’t get out of hand. Something I’ve tried at a company I work for in the past is to base branches on cases or a group of cases. In the particular project manager we had you could group cases/features, so we would base our branches on that, which worked out pretty well.

There is a pretty good simple explanation on SVN best practices here: http://www.duchnik.com/tutoria.....-practices

By Spike October 30, 2006 - 1:56 pm
There are many ways to approach branching and use it heavily to the benefit of your projects. I have used the flying fish approach on several projects and found that it removes some problems common to most revision control systems. Most notably, the ability of each developer to tag, track and commit on their own branch without worrying about how it will affect others. Merging becomes a more involved and complex process, but the benefits can outweigh that; particularly if you are working with a distributed development team who aren’t always within easy access if something is wrong with the code they committed the night before.
There’s a good section in the “Open source Development with CVS” book dedicated to the discussion of branching. It includes a good description of flying fish and a couple of other approaches. Although the book is written for CVS, the branching chapters apply equally to Subversion.
Here’s a link to save you the time of googling for it: http://computing.ee.ethz.ch/se.....html#SEC84
By Brandon Harper October 30, 2006 - 2:54 pm
Thanks for the link Spike, I hadn’t seen that before (especially being a VSS convert).
As for a bit of irony, we actually started off doing the “Flying Fish” method of branching listed on that site and found it very troublesome because of all of the commits occurring in many different places, as well as not being able to see the full, incremental history in trunk.
I suppose with as with all things technology related, the right answer starts off with “it depends”; I thought I’d just pass on something I thought was good as well as some personal experiences and observations.
By Spike October 30, 2006 - 10:41 pm
Yeah, that’s in line with my experience, in some cases it causes more problems than it solves, but for distributed development, especially where the project has different teams that work semi-autonomously, it can be very useful which is why I mentioned it.
By Pete August 18, 2009 - 2:55 am
In my experience separate branches for major pieces of work cause problems at merge time. We have had different projects working on different branches all scheduled to leave at the same time. The problem comes when you merge, the first merge is typically painless but the last one is horrendous, what’s more is the branches themselves become stale and the only visibility you have is at integration. This can however be mitigated with SVN as is nicely handles merges from trunk to branch and ultimately back again.
By Best Practice Visual Studio with SVN, VCS and SCM « Kevin Steffer October 12, 2009 - 11:21 am
[...] http://devnulled.com/content/2.....branching/ [...]
By KD Web Dev: Subversion Best Practices December 8, 2009 - 7:37 pm
[...] http://brajeshwar.com/2007/sub.....ick-notes/ http://devnulled.com/content/2.....branching/ http://www.karlkatzke.com/best.....ubversion/ [...]
By Rob March 2, 2011 - 12:14 pm
I think when it comes to branches there should be some basic decisions made so that it doesn’t get out of hand. Something I’ve tried at a company I work for in the past is to base branches on cases or a group of cases. In the particular project manager we had you could group cases/features, so we would base our branches on that, which worked out pretty well.
There is a pretty good simple explanation on SVN best practices here: http://www.duchnik.com/tutoria.....-practices