monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] mtn diff --../monotone-0.35/roster.cc:188: invarian


From: Derek Scherger
Subject: Re: [Monotone-devel] mtn diff --../monotone-0.35/roster.cc:188: invariant 'fetching nonexistent entry from children' violated
Date: Mon, 20 Aug 2007 23:29:25 -0600
User-agent: Thunderbird 2.0.0.6 (X11/20070805)

Rob Schoening wrote:
> I found a semi-obscure bug (#20447) with directory renames.  Note that
> it might be a duplicate of #20125, but since #20125 had no steps to
> reproduce, I went ahead and opened a new one.  I wouldn't post it to the
> list were it not for the fact that these assertion failures are so rare
> now.  ;-)
> 
> "mtn diff" fails consistently with the following error:
> 
> mtn: fatal: std::logic_error: ../monotone-0.35/roster.cc:188: invariant
> 'fetching nonexistent entry from children' violated
> mtn: this is almost certainly a bug in monotone.
> mtn: please send this error message, the output of 'mtn --full-version',
> mtn: and a description of what you were doing to
> address@hidden <mailto:address@hidden>.
> mtn: wrote debugging log to C:/dev/temp/test/_MTN/debug
> mtn: if reporting a bug, please include this file
> 
> Steps to reproduce on Windows & *nix:
> 
> 1) Given a directory and file dir1/test.txt
> 2) mtn mv dir1 dir2
> 3) edit dir2/test.txt & change content
> 4) mtn diff dir2/test.txt
> 
> Note that (4) will not fail unless you perform both
> steps (2) and (3).

I've (finally) added tests/restricted_diff_bug (xfailed) that exposes
this and I think I've figured out what's going on. *If* you don't
understand the internals this may not make much sense. ;)

We take the pre and post rosters and create a pair of csets in
roster.cc's make_restricted_csets. The intent is that the first of these
(the included cset) includes those changes that are in the restriction
and the second of these includes the remaining changes that are not in
the restriction.

For reference, the pre roster contains:
node 1 (root)
node 2 (dir1)
node 3 (dir1/test.txt)

and the post roster contains:
node 1 (root)
node 2 (dir2)
node 3 (dir2/test.txt)

the included cset contains
patch dir2/test.txt <-- this is the problem
 from [...]
   to [...]

and the excluded cset contains
rename dir1
    to dir2

the patch line in the included cset should be referring to dir1/test.txt
not dir2/test.txt since the rename has been excluded. Attempting to
apply the included cset to the original roster fails because there's no
dir2 in the roster.

I think the problem is in make_restricted_csets but I don't see any nice
way to fix it. We need to do something like invert the renames in the
excluded cset and apply only these to the post roster and then generate
a new pair of included/excluded csets that are correct and this doesn't
sound particularly elegant. It's been a while since I looked at this
stuff though so maybe someone else will have a more reasonable idea. ;)

I've also added tests/restricted_revert_bug that exposes another problem
that is probably related. Replacing 'mtn diff' in the above with 'mtn
revert' I would expect the patched content of dir[12]/test.txt to be
reverted but not the rename of dir1 to dir2. What actually happens is
that *nothing* is reverted. I haven't really looked into the details of
this yet but it's likely a very similar problem.

This same problem is likely also what causes some issues with the
experimental basic_io automate inventory and another problem that Rob
describes.

Cheers,
Derek





reply via email to

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