Re: [Caml-list] [OT] Rant about VCS: Conclusions

[David Brown <caml-list@davidb.org>]

On Wed, Dec 22, 2004 at 09:36:27AM +1100, Erik de Castro Lopo wrote:

> Arch OTOH keeps a log of all changesets applied to a tree. That 
> means that if you have three branches A, B and C, all with the same
> common ancestor you can merge A -> B and then B -> C. Now if you
> try to merge A -> C Arch is clever enough to figure out which
> changesets in A have already been applied to C and which ones 
> haven't, and then only apply the ones that have not been applied.

As far as I know, Arch and darcs are the only reasonably popular SCMs that
keep track of merge history sufficiently.  (I know nothing about BK, since
I'm not allowed to run it, it probably does track this correctly).  PRCS
was probably the first to popularize this level of tracking of changes.

It is a deeper issue than just knowing which changes to apply.  When you
have two active branches where changes propagate between them (common when
there are two active branches), a solution other than Arch, or darcs
quickly becomes unmanageable.  The solution with most other SCMs is to just
not do this, but it is a realistic scenario, especially when there are
specific "customers" for specific releases.

Darcs and Arch take very different approaches.  Arch approaches this from a
'patch' model, where it tries to find a common ancestor, and apply the
appropriate patches to this ancestor, allowing the patch program to try and
deal with the differences.

Darcs, instead, has the ability to mutate the patches themselves to be
applicable in different contexts.  It has the advantage of being completely
deterministic as far as conflict resolution.  It also has the problem that
in some instances, it just gives up, declaring that a patch cannot be
applied, rather than trying to do so and letting and edit of the conflict
take place.

The implementors Arch and Darcs seem to understand the complexity and
difficulty of cross branch merging, and embrace it head on.  Other
solutions tend to brush off the problem as not important, and generally
leave the user with some very tricky merge cases.

Perforce (commercial) attempts to track merge history, but does a terrible
job of it.

Aegis does seem to track merges well, although it can be obscure figuring
out what commands are needed to apply the merges.  I've also had problems
where it applied the merge correctly, and them completely undid the change
when 'resolving' the conflicts.

Dave