[Top][All Lists]

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

Re: [Monotone-devel] Bogus merge with 0.38

From: William Uther
Subject: Re: [Monotone-devel] Bogus merge with 0.38
Date: Mon, 4 Feb 2008 10:51:40 +1100

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


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

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/ 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         :-}

reply via email to

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