[Monotone-devel] Re: merging interface

[Bruce Stephens]

Christof Petig <address@hidden> writes:

[...]

> What do you think about the proposals in thread
> http://lists.gnu.org/archive/html/monotone-devel/2004-05/msg00045.html
> (continued at)
> http://lists.gnu.org/archive/html/monotone-devel/2004-06/msg00081.html

Ah, good.  That answers my original question, which was really "am I
the only one...".  I think the discussion was before I first
encountered monotone, which would explain why I didn't remember it.

> It seems to me that the conclusion was a reasonable design though
> Graydon was not overly fond of adding the feature of a partially
> merged tree.

Yes, although the design (if I understand it correctly) seemed to
involve merging the heads and committing a "best guess" merge, which
could then be worked on.  

Intuitively, I'd see the cases in the following order: merge3 works
automatically; a short amount of work fixes the remaining conflicts;
the merge is awkward, and can usefully use more than one person's
effort.  So I'd like to optimise for the first two cases, where
nothing needs to be committed until the merge is complete.  However, I
can completely understand the desire to get something that'll work for
the tricky cases.

I'm also unsure about how to deal with tree conflicts.  GNU Arch does
it (IIRC) by holding manifest files that map between "arch tags"
(stable unique identifiers for files) and file paths; those files are
just text files, so they can conflict (and have their conflicts
resolved) by using normal text tools.  That doesn't work if you don't
have stable unique identifiers for files, of course.  However, maybe
one could construct something useful basing things on the ancestor
manifest naming (so one would merge two files containing lines
"old-name new-name").