Reflections on SCM Branching strategies
The upcoming Subversion 1.5 makes huge progress in the way you do branching, at least in the CVS/SVN world. This got me thinking about branching strategies.
Traditionally, in both CVS and Subversion, if you want to merge some changes from a branch back into the trunk, you need to specify the changes you want to apply. As in "I want to merge the changes made between revision 157 to and revision 189 on branch B back into the trunk". In Subversion 1.5 (which isn't out yet), you just say "Merge the changes from branch B back into the trunk". Subversion will figure out what has already been merged, and only apply the new stuff. This is very cool, and makes it a lot less disuasive to consider merging between branches. I discussed this in some detail in http://www.javaworld.com/javaworld/jw-01-2008/jw-01-svnmerging.html.
Anyway, this got me thinking about branching strategies. From what I've seen, there are two common strategies.
In the first approach, your development work goes in the main trunk. Branches are for releases or possibly for isolated changks of work. You create a new branch whenever you release a version into a new environment (UAT, production, whatever). Bug fixes made in the release branches can be merged back into the development trunk as required. This strategy has the great merit of simplicity.
In the second approach, your trunk contains the production-ready code. Branches are for milestone releases. This means you can have separate teams working on different releases, and theoretically work more efficiently in parallel, but this sounds a bit complicated to manage to me.
There are also other approaches, though. One interesting one is to adopt a much more agile stragegy. Create a new branch for each new user story/feature/whatever. Then merge it back into the trunk when it's ready to be integrated. You would also need branches for production releases as well, I suppose. This strategy would let individuals or small groups work on specific features/user stories, and merge them into the main trunk when they are ready.
One interesting question for this approach is how would you set up Continuous Integration with this approach. For example, you might have separate CI jobs hooked into each user story branch, as well as another job running against the main branch.
John is a freelance consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Wellington, New Zealand. Well known in the Java community for his many published articles, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in open source technologies, SDLC tools, and agile development processes. John is principal consultant at Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 57 posts at DZone. You can read more from them at their website.
- mr_john_smart's blog
- Login or register to post comments
- 4210 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Ürgo Ringo replied on Thu, 2008/02/14 - 7:21am
About the third approach. I think it has two problems:
1) big overhead of merging
2) according to agile you should integrate very frequently but if everybody is working in separate branch then it may easily lead to big bang integration
Glenn J. Mason replied on Thu, 2008/02/14 - 2:54pm
in response to: yrgo
1) big overhead of merging
2) according to agile you should integrate very frequently but if everybody is working in separate branch then it may easily lead to big bang integration
[/quote]
It's a good point -- what is the overhead for merging in Subversion 1.5? Is it something that can be (almost always) automated? CI does mean you should quickly know if something you're doing is conflicting with something someone else is doing, but couldn't you still have a integration-build service that says "automerge everything and attempt to build it every n minutes"?
If each user story (whatever) has it's own branch, and one (or one pair of) developer(s) are implementing on one branch then it's kind of like having a "personal" revision-control system i.e. a little like Bazaar.
So long as merging can be automated -- seriously, can it? -- then I think you can avoid big-bang integration.
John Edwards replied on Sat, 2008/02/16 - 6:58pm
Just for the record, I'm using the first approach and it seems to me that most people are taking that approach (at least, that's my personal experience, I might be mistaken).
Even without the merge tracking of SVN 1.5 it's not an overly complex approach. If you want to merge the branch to the trunk multiple times, you do have to remember the revision number of each previous merge. Namely, you have to use this revision number as the 'start revision' for the next merge. This is actually but a small thing to do. You can either write the number down or supply it in your commit message. No big deal really. (this approach is explained in more detail in the official SVN manual)
Of course, merge tracking brings with it some other advantages, like remembering the original author who made the change in the branch, instead of remembering the person who did the merge.