[darcs-devel] Requirements for merging

[Anthony Towns]

Hi,

Still trying to grok what merging is about :)

So, I think there are a range of different things implicit in "merging":

   a) That when you merge R+B into R+A to get R+A+(B)+C, you can easily 
(automatically, with no conflicts) merge this back into R+B (to get 
R+B+(A)+C) and have the same repository.

   b) That when you're in the process of merging R+A and R+B you end up 
with a repository/working directory that reflects the changes from R in 
both A and B, in a form that's easy to navigate and understand, and thus 
resolve.

   c) That when you've merged R+A and R+B to get R+A+(B)+C, merging 
further changes from either branch, such as D from R+A+D to get 
R+A+(B)+C+(D), is as easy as possible.


Do those sound reasonable? I'm trying to go from darcs-agnostic first 
principle's sort of approach. Should there be more, or is there a better 
way of describing them?


AFAICS:

darcs gets (a) completely right; if it didn't it probably wouldn't be 
able to cope with being so decentralised.

darcs gets (b) mostly right -- it's fine for conflicting hunks, and 
conflicting addfile/moves, but breaks down for conflicting 
addfile/addfiles. Having pretty GUI tools like Bitkeeper does would be 
even better, of course.

darcs gets (c) completely right for non-conflicting merges, but 
completely wrong for conflicting merges.

I *think* arch/tla gets all of them right, by contrast. The disadvantage 
arch has (aiui) is that the way it gets them right is by having fuzzy 
patches, which probably limits it from supporting things like "replace"
patches.

(I blogged about this topic last night at
     http://azure.humbug.org.au/~aj/blog/2004/12/11
though that's more "stream of consciousness" than anything. Also fwiw, 
some more darcshive notes at
     http://azure.humbug.org.au/~aj/blog/2004/12/08
)

Cheers,
aj