Could you please suggest an article, a book, or a conference paper about possible problems a software team may experience with branching in version control environment? We're creating a summary for one of our sponsors, and need to quote respectable sources of information. So far I've found short reviews by Chris Birmele and Eric Sink.
Thanks in advance!
ps. The article Branching Patterns for Parallel Software Development by Appleton et. al looks fundamental, but rather old.
Look at Hg Init - it explains in detail why branching is very problematic in certain cases and how to mitigate this problem. The key point is that branching is not a problem at all, but merging back changes on different braches can consume a lot of time.
As mention in Martin Fowler's Bliki, FeatureBranch can have their issue with semantic conflicts.
The problem I worry more about is a semantic conflict.
A simple example of this is that if Professor Plum changes the name of a method that Reverend Green's code calls.
Refactoring tools allow you to rename a method safely, but only on your code base. So if G1-6 contain new code that calls foo, Professor Plum can't tell in his code base as he doesn't have it. You only find out on the big merge.A function rename is a relatively obvious case of a semantic conflict. In practice they can be much more subtle. Tests are the key to discovering them, but the more code there is to merge the more likely you'll have conflicts and the harder it is to fix them.
It's the risk of conflicts, particularly semantic conflicts, that make big merges scary.
See example of semantic conflicts in this SO question.
Once that is taken into account, you need also to differentiate CVCS and DVCS (Centralized vs. Distributed VCS), as a DVCS will bring an orthogonal dimension to branching: "publication" (push/pull to/from remote repositories, meaning you can work on the "same" branch, while still being in complete isolation because you are working on a local cloned repository).
CVCS like SVN have their own issues with merging branches, which DVCS are supposed to be very good at.
See also "When should you branch?"
I'm sorry I cannot find a reference to the actual statement, but I recall Larry McVoy saying something along the lines of "you never want branches to multiply, you always want to merge branches back together again". The longer your branches are outstanding, the more likely it is for changes in one to conflict with changes in another. Feature branches are your friends, but I do recommend pulling changes often enough to keep abreast of changes in the moral equivalent of 'trunk' or 'upstream', and be sure to merge branches back into 'trunk' or 'upstream' as soon as their need is fulfilled.
Perhaps more succinctly, I've always found it useful to define the lifetime of a branch before creating it. Know why you're creating a branch, how long it will survive, when you'll decide to merge it or throw it away.