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

[Richard Levitte - VMS Whacker]

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.

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?

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?

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis