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 :-}
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
