command.revert(rev=rev, all=True) has timing dependent results after former commit
greg-hg at gerg.ca
Tue Oct 25 17:25:37 CDT 2011
On Tue, Oct 25, 2011 at 5:52 PM, Peer Stritzinger <peerst at gmail.com> wrote:
>> What version of Mercurial are you testing with? We fixed a rather
>> subtle race in dirstate back in 1.9.
> Oh sorry how could I forget: I'm running Mercurial 1.9.1 on FreeBSD
> 8.2 amd64 with Python 2.7.2
> Does this mean you thing thats a bug in dirstate?
Well, it's *not* the bug we fixed in 1.9. ;-)
What I learned from that epic fix (it took me something like eight
months to produce a 10-line patch, working sporadically!) is that you
can't rule out bugs in dirstate when something timing-dependent is
going on. Yeah, that's a gross generalization, and it's much more
likely to be a bug in your extension (sorry).
Here's what I would advise: start with your extension as it stands,
reproducing the timing-dependent bug. Then strip out fluff (= code
that you suspect is unrelated to the bug) gradually. Either you will
accidentally make it work with one removal -- which indicates that you
just removed the guilty code from your extension -- or you will strip
it down to a boneheaded obvious "of course this should work" case that
indeed demonstrates a bug in core Mercurial.
Incidentally, the bug we fixed in 1.9 was this:
* two commits in the same process (and same repo lock)
* happening within the same second
* modifying the same file
* where the second commit leaves the file size unchanged
... would make the second commit not happen, i.e. Mercurial thought
"nothing changed". So keep in mind that those are the sort of
circumstances that indicate a possible dirstate bug. I hope we don't
have another one!
Oh yeah: you might also try it with the current tip of stable, since
Mercurial 2.0 is coming out in a few days.
More information about the Mercurial-devel