Re: [Monotone-devel] cooperative/parallel/resumed merging

[Nathaniel Smith]

On Tue, Jun 22, 2004 at 07:35:09PM +0200, Patrick Mauritz wrote:
> On Tue, Jun 22, 2004 at 12:31:27PM -0400, graydon hoare wrote:
> >          +---- LEFT  -----+                 +--- RESIDUAL LEFT
> > --- ANC1 +                + -- SEMIMERGE -- +
> >          +---- RIGHT -----+                 +--- RESIDUAL RIGHT
> > 
> > I'm not really sure this is the "least expected" situation; the two new 
> > residual heads look like "slightly more similar" versions of the 
> > previous two heads. otherwise it's the same situation.
> basically it merges everything from left and right that does not conflict
> with changes of the other side. the result ("semimerge" here) will likely
> be broken, too and "residual (left|right)" will probably not work out of
> the box either.

Yeah, the residuals are almost certainly broken, in all but the most
simple of cases.

> unlike conflict markers this approach still allows to make use of the
> development tools that monotone provide, namely versioning and diffs
> (how often did you forget a conflict deep inside your sources?) as well
> as interactive merging using the "normal" tools.

But you still need to add a way to do a "partial interactive merge",
that lets you inspect the various conflicts, choose two to resolve
right now, finish resolving the second and go back to change how you
resolved the first, and then commit just those two resolutions.  This
is why people want a way to do merge outside the database, because if
it's sitting on your disk you can apply all your normal tools to do
this, when monotone can't do anything like that right now.  (And it's
not clear one really wants it to.)

I really dislike conflict markers, though; monotone gains a lot from
its philosophy of not screwing around with the user's data, and
sticking to pure 3-way merge as the one and only merge technique.
And merge-into-working-copy loses you the ability to collaborate on
merges.

Here, I'll throw out a third proposal:
  -- Define a new subdir, ".mt-unmerged/".
  -- When file "foo/bar" encounters conflicts, we stick
     something-or-the-other at "foo/bar" (maybe the ancestor
     version?), and create files
       .mt-unmerged/foo/bar/{left,right,ancestor}.
  -- A file f is considered unmerged if .mt-unmerged/$f exists.
     If any such files exist, "monotone status", the comments that get
     stuck into the commit message editor, etc. all say "There are
     unresolved conflicts." or similar, just to let you know, so you
     don't accidentally commit back to the main branch until you've
     resolved all conflicts.
  -- To make things more ergonomic, define some utility commands to
     list remaining unmerged files, attempt to merge a file (by
     calling the normal merge hook on the appropriate files[1]), mark a
     file as merged, etc.

Major problems:
  -- Wacky things can happen if you two people resolve some conflict,
     but disagree about how to do it, and you then try to merge those.
     (Actually, it works really nicely if both parties fully merged
     the file containing the conflict, but if they've only partially
     merged, then ick.)
  -- Doesn't contemplate tree layout conflicts, don't see how they
     could be retrofitted on (except by, you always have to resolve
     tree layout conflicts immediately at the beginning, which is
     suboptimal).

I don't think any of the other ideas suggested so far does better on
either of these points, though.  Hrm.

[1] Really you want a 'merge4' (?) command for this; one that takes
    ancestor, left, right, and partly-merged-child, where the last is
    used to set the default result for conflicting hunks.  I dunno if
    any of the standard merge tools support this mode of operation,
    though...

-- Nathaniel

-- 
"...these, like all words, have single, decontextualized meanings: everyone
knows what each of these words means, everyone knows what constitutes an
instance of each of their referents.  Language is fixed.  Meaning is
certain.  Santa Claus comes down the chimney at midnight on December 24."
  -- The Language War, Robin Lakoff