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.
6 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
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
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.
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.
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.
Continuing the Discussion