Re: [Monotone-devel] Bogus merge with 0.38

[William Uther]

On 04/02/2008, at 4:32 AM, Julio M. Merino Vidal wrote:

> Hello,
>
> I was doing a change to a workspace when I realized that I could  
> better split it in two different commits.  So I checked out a fresh  
> revision of the single-head I had, made part of the change and  
> committed it.
>
> Then I went back to the former repository, which already had the  
> whole changes applied (the part I already committed and the rest)  
> and did an update.  I expected some conflicts might arise, but not  
> what happened.
>
> First, look at the following messages printed by mtn (0.38 release  
> under OS X 10.4.11):
>
> ----- cut here -----
> calypso:~/Projects/atf/src> mtn update
> mtn: updating along branch 'org.NetBSD.atf.src'
> mtn: selected update target 6c776507a34b435d02334f1771a99c365c5841a3
> mtn: warning: Content changes to the file "subrs/atf.config.subr.in"
> mtn: warning: will be ignored during this merge as the file has been
> mtn: warning: removed on one side of the merge.  Affected revisions  
> include:
> mtn: warning: Revision : 0000000000000000000000000000000000000004

That error message was introduced is revision  
a71b546a834a4ac9561d57e9747e69312c1a6b80

It is a recent change.  The code is in the insert_if_unborn() function  
in roster_merge.cc.

insert_if_unborn() is used to add a node to the new revision of a  
merge if it only exists on
one side of the merge.  The new code is inserted in the if_not_unborn  
side of the if_unborn if
statement.  There used to be nothing there - the node was dropped  
because of die-die-die merge.

The new code simply outputs the warning you see.  The revisions listed  
are the content marks on
the file that are in the uncommon ancestor set.

This raises a few questions...

i) Why does monotone think the file subrs/atf.config.subr.in has been  
deleted on one side of the merge?  Had it been?  If not, had it been  
added on only one side of the merge?

ii) Why is revision 0000000000000000000000000000000000000004 in both  
the marks of the file and the uncommon ancestor set?  I assume this is  
a bogus revision ID?  (It is technically vaild, just... unlikely.  Can  
you mtn log --from 0000...0004?)

Something weird is going on.  I find it hard to see how that change  
could have broken anything - but it is revealing something weird going  
on in the uncommon ancestor set and content marks.

I don't suppose this is repeatable?  i.e. If you run mtn diff can you  
get a diff of your changes from a known revision.  Then check out  
fresh working copies, use patch to apply your changes, and then see if  
you can repeat the whole mess.

Be well,

Will         :-}