[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] Re: 3-way merge considered harmful
Date: Mon, 02 May 2005 22:05:49 +0200 (CEST)

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 
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> 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

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> 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

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?


Please consider sponsoring my work on free software.
See for details.

Richard Levitte                         address@hidden

"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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]