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 implies 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