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

[Richard Levitte - VMS Whacker]

In message <address@hidden> on Mon, 2 May 2005 16:25:09 -0700, Nathaniel Smith 
<address@hidden> said:

njs> On Tue, May 03, 2005 at 01:21:31AM +0200, Florian Weimer wrote:
njs> > I think Nathaniel wanted to say that there is an implied conflict
njs> > which 3-way merge cannot detect, not that one choice is better than
njs> > the other.  The argument that there is a hidden conflict which should
njs> > be flagged as such is quite convincing (and, as a result, the "zombie
njs> > changeset" term is misleading).
njs> 
njs> Hmm, I'm not sure how I managed to be this unclear, but somehow I did
njs> :-).  Let me try again.  We have B, C, D:
njs>     B
njs>    / \
njs>   C   D
njs> There is a certain file, call it "foo", which exists in B.  The
njs> person who created C elected to delete "foo".  The person who created
njs> D didn't do anything involving "foo" at all; they were working on some
njs> totally unrelated file.  When we merge C and D, there is no conflict;
njs> "foo" should disappear in the merge, because the only action any user
njs> has taken was to delete "foo", so that action can't have conflicted
njs> with any other actions.  "foo" should be dead, it is an ex-file, etc.
njs> 
njs> However, if we add in A, a parent of B, that happens not to contain
njs> "foo", and for some reason use it as our merge ancestor, then
njs> something strange happens -- suddenly, it looks like "foo" was
njs> _added_, not deleted.  "foo" mysteriously rises from the dead, and the
njs> poor developer who created C has his actions silently reverted.

For me, it became clear what happens the first time you told us.  What
you're basically telling us is that in a merge, where the common
ancestor is farther away than the nearest fork, monotone loses track
of file rearrangement (rename and delete) information.  If a merge is
only based on file content changes between each merge source and the
common ancestor, this is not really surprising, as there's no way to
encode file rearrangement (except for added files) information in a
diff (as far as I understand you, the A->C and A->D changesets are
basically viewed as diffs), as far as I know.

Is what I'm saying so far correct?  If not, what would be the
explanation for 'suddenly, it looks like "foo" was _added_, not
deleted'?  It looks very much like file rearrangement history was lost
on the way.

So, the way I see it, we need to figure out a way for monotone to keep
track of file rearrangements that happen along the way (i.e. the
delete that happens on the B->C edge).  It's possible cdv-merge is the
way to go, but as far as I understand, it isn't quite finished yet...
And I'm not yet convinced codifying rearrangement in a virtual file is
such a bad thing.

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