star or parallele merge

[Matthieu Moy]

Aaron Bentley <aaron.bentley at utoronto.ca> writes:

> Using just two branches sounds fine, in theory.  I don't really
> understand why you're using three brances with tla, so I can't be sure
> that bzr handles the issue better.

Actually, a two branch organization is a particular case of star
anyway (you can decide any of the two to be the main branch, and the
other one to be a contributor).

With more than two (say, A, B, C and D), it's more problematic,
because when A writes a patch, both B and C can merge it
independantly, and then, with tla, D will be in troubles if he merges
from B and C. We had the problem at the early stage of Xtla's
development (conflicts, and sometimes silent apparition of code
duplication when people merged code addition twice). First, we wrote a
tool to help chosing the right version to merge from and avoiding
having a patch merged twice from different sources, and then we
decided to come back to a star-shaped patch flow (one master archive,
and others contributing to it, and not merging from each other).

I suppose the kind of problematic merge I described above is what you
call "mesh merge", which baz should support better (I haven't tried).
According to http://bazaar.canonical.com/CanonicalBzrDogfooding , this
"looks done" for bzr.

I also suppose that a merge operator based on weaves will have less
problems with this (code duplication won't happen, since each line of
code has a unique identifier).

-- 
Matthieu