Different approaches to source control branching

Question

When using source control, the way I am used to working is to develop on the trunk and then branch the trunk just prior to moving into QA.

I was talking with some other people in the department and apparently there are some passionate views about a different way of working, which would be to create the new branch at the very beginning of the development cycle, do development work on that branch, and then merge it back to the trunk at the end. The idea on this approach is to keep the trunk pristine.

While I'm highly skeptical of the claim that one proponent made that the latter approach is the "standard" approach (though happy to be told otherwise), I wouldn't be surprised to hear that it is fairly common. I can imagine some benefits to that (easier to pick and choose when to deploy which feature or set of features) but also some drawbacks (potential merge issues since every single branch must be merged back to the trunk).

Did some subsequent research and found this: http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-introduction.aspx

Would be curious to hear from people their sense for the relative strengths and weaknesses of these approaches are, and also about any other approaches that people may be using.

Answer 1

This is a very similar question to this previous SO item:

http://stackoverflow.com/questions/1261825/subversion-should-anyone-be-developing-off-the-trunk/

Not exactly identical, but a lot of the concepts in the responses are the same.

My personal opinion? The trunk is for active development; development lines of older versions that you want to keep "pristine" should be held in version branches (and tags for releases). You can still try to maintain a "the trunk should always compile" maxim even with active development being on trunk.

Answer 2

With one team working on the same stuff, it's quite a nice approach to work in the trunk, and create a branch prior to release. You minimize merge-hell, and you have a distinct branch for every release if you have to do a patch, or go back for some reason.

But, when working with mutiple teams doing separate things, this won't work since they will most certainly collide in the trunk. I have not much experince about this so I'm looking forward to some ideas around that. One approach would be to have multiple branches, one for each team perhaps, and then merge those branches that are going into the release in the trunk. (I can only imagine the frustration) :)

Answer 3

I favor keeping the trunk clean. This allows compiling a working version at any time, to release a fix, a beta, create a demo version ...

Changes are done on separated branches. This gives a better traceability, and one can take advantage of the source control on the branch and check in interim versions. In a ideal world, merge issues are covered by [automatic] tests. The sooner you integrate the changes into the trunk the better.

Do not put untested code on the trunk as this will eventually slow down someone.