Re: [Monotone-devel] Re: 3-way merge considered harmful

[Nathaniel Smith]

On Mon, May 02, 2005 at 10:05:49PM +0200, Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on Mon, 2 May 2005 03:35:49 -0700, Nathaniel 
> Smith <address@hidden> said:
> 
> njs> On Mon, May 02, 2005 at 12:25:08PM +0200, Richard Levitte - VMS Whacker 
> wrote:
> njs> > I disagree with that conclusion.  It's quite possible the removal of
> njs> > the file in the B->C edge is a mistake, and that the person leaving it
> njs> > along in the B->D edge had it right.  Especially in a fairly loose
> njs> > network of cooperating programmers, disagreements of that kind are
> njs> > bound to happen (and have happened).  Others might call them "oopses"
> njs> > rather than disagreements...
> njs> 
> njs> Err... so you propose that it's okay if we have a merge algorithm
> njs> that sometimes simply reverses people's changes, with no warning
> njs> or reason, because hey, they might have been a bad change?
> 
> Uhmm, no, and reading the rest of what I wrote, you probably already
> realised I wasn't thinking anything like that at all.  Quite the
> contrary.
> 
> What I'm saying is that in cases when file rearrangement differs
> between branches or forks, monotone can't really know which movement
> (or lack of movement) is correct, and this should be brought to the
> attention of the developpers.

Hmm, no, I'm not understanding what you're saying here at all.  In the
example, someone deleted a file.  Someone else did something
completely unrelated, maybe they edited a file way over in another
part of the source tree or something.  When we merged the delete with
the unrelated changes, we reverted the delete.  There is no
disagreement here; we're just randomly undoing people's work for no
reason.

If what you mean is that we should detect actual _conflicts_ in tree
rearrangements, like when we each tried to rename the same file to two
different names, then yeah, definitely.  But we already do that; it's
irrelevant to this bug.

> njs> Trying to code tree rearrangement conflicts as textual conflicts
> njs> doesn't work; I spent a few weeks trying, when we were trying to
> njs> figure out how to do tree rearrangement in the first place.  You can
> njs> conflict on moves that have the same source, or you can conflict on
> njs> moves that have the same destination, but you can't detect both at
> njs> once... (and good luck with directories!)
> njs> 
> njs> I'm pretty sure the right UI to tree rearrangement conflicts is
> njs> merge-via-working-dir.
> 
> Really?  How is a lost rename like the one in my case treated through
> that?

Well, umm, there was no conflict in your case (either detected or
real), so I dunno how to answer this :-).

> njs> This doesn't address the problem.  Everything you say here, we
> njs> effectively do; we do track renames, adds, report conflicts then
> njs> they conflict, etc.
> 
> Uhm?  Yes, renames and deletes are tracked from one revision to the
> next are tracked, and the effect is correctly tracked as long as the
> changes are made in the working directory.  However, from what you
> say, it seems those are forgotten when composing the changeset between
> distant revisions during a in-database merge.  Otherwise, how do you
> explain the faults that are discussed here?

Because our merge logic is buggy, not because we don't store the
correct information.  (In fact, Matt reports hitting a new invariant
failure, that is probably a result of us now having this inconsistent
stuff in the tree, which wouldn't happen if we weren't actually
paying attention to the inconsistencies...)

It really is the case in the above that the changeset from A to C and
A to D both just have an add_file in them.  We didn't forget anything
there.  The problem is that just looking at those changesets doesn't
turn out to be enough to do correct merging.

-- Nathaniel

-- 
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."