Why not to Merge back

Before we go to the advantages of in-place delivery, one should consider the obvious fact that merging back to a main branch defeats all the reasons which made branching a good idea (home merges are of course still needed and valid)!

It brings back all the problems that branching helped to solve: there is again a successor the state of which becomes a bottleneck!

In particular, the main branch has to be mastered in one site, with all the implied synchronization problems (including this of avoiding the problem by enforcing a hierarchy: jeopardizing management in the name of control).

The idea of merging back would never have come to anybody, if it had not been there first, i.e. if SCM had not developed from a single-branch backup system. In short, this is a hysterical idea.

The other problems (thus beyond synchronization/locking/waiting) artificially brought in by delivery-merging are:

• irreversibility: one can only undo a delivery in either of two ways:
  • by losing history
  • by faking a revert, whereas one actually adds new versions building up a state different from and more complex than the original one.
• invalidating all the derived objects, thus creating a race condition to produce new ones identical to the ones obsoleted, but using the versions duplicated from the original ones into the main (integration etc...) branches.
• making it possible for developers to use different copies of the duplicated versions, and thus for them to diverge.

-- MarcGirod - 24 Sep 2007