To Branch or Not To Branch (and Merge/Test)

chances of parallel checkout.

Similarly, if your process imposes arbitrary check-in freezes while a switch to a new main is in progress, you're likely to incur more parallel change hits, and have a resulting increase in merges. Other things which can cause more parallel checkouts include the treatment of dependencies. If one change is dependent on another and you have to keep both changes checked out until they're both ready, you may be again widening the parallel checkout window. If instead, you could check the change in without it being pulled until you signal all the changes are in and ready, those files are ready for checkout again and don't require parallel checkout and merging.

Summary

I'm not trying to get you to avoid branching, but to have a healthy respect for branching. Branches incur complexity and overhead. If you complicate a branching policy to handle 1% of the cases, you may be incuring more overhead that if you just said no to branching and modified your process accordingly.

But as well, I'm saying that, for the most part, use branches only for parallel development streams. If you have good tools, this model will give you dramatic payback in simplicity. It will reduce training and confusion. It will keep your branching sane, and easy to understand.

I swear by this approach and rarely, if ever, create a branch which is not a release stream branch. On small projects (<100K LOC and a few developers), to very large projects (40M LOC and hundreds to thousands of developers), it has worked. On top of that, I've often used it with an Exclusive checkout only policy, encouraging rapid turnaround of changes to files which might otherwise be under contention for parallel checkouts. This isn't to say developers don't do parallel checkouts on the side (i.e. without telling the system). But there is a level of discouragement. The benefits accruing from the simplicity of such a model, are so large that, in my opinion, they can't be ignored. Agile development is more easily supported because developers are making changes to the main branch (for their target releases) rather than branching and merging and merging again for promotion.

But it won't work without good tools and good process support. It won't work without first order objects to replace the overloading of branches. And there are a number of other branching scenarios I haven't even covered (e.g. does your multiple site capability force you to branch in order to do work at a different site?). Still, for over a quarter of a century on some sizable projects, I could not imagine working any other way and keeping my sanity.