Question

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.

Answer 1

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?“