changeset:   9858:ea38a2c1bdd3
user:        Benoit Boissinot <benoit.boissinot@ens-lyon.org>
date:        Mon Nov 16 11:55:29 2009 +0100
summary:     lock: the correct way to do a trylock() is to use a timeout 
of 0

changeset:   9859:951ec6c7d703
tag:         tip
user:        Benoit Boissinot <benoit.boissinot@ens-lyon.org>
date:        Mon Nov 16 11:58:03 2009 +0100
summary:     inotify: workaround test-inotify-dirty-dirstate failures


First one is a fix for the lock warning, the second one workaround the 
failure until a proper fix is issued (workaround was provided by Nicolas).

Not yet in hg-stable (only crew-stable), therefore at most 'testing'.

But anyway, now I get this when running 'make tests':

ERROR: test-inotify-dirty-dirstate output changed
--- Expected output 
+++ Test output 
@@ -1,9 +1,14 @@
 % issue1810: inotify and fetch
 adding foo
-updating working directory
-1 files updated, 0 files merged, 0 files removed, 0 files unresolved
+/tmp/thomas/hgtests.SAA3Py/install/lib/python/mercurial/lock.py:80:
DeprecationWarning: use lock.release instead of del lock
+  locker = self.testlock()
 adding bar
+/tmp/thomas/hgtests.SAA3Py/install/lib/python/mercurial/lock.py:80:
DeprecationWarning: use lock.release instead of del lock
+  locker = self.testlock()
 adding spam
+/tmp/thomas/hgtests.SAA3Py/install/lib/python/mercurial/lock.py:80:
DeprecationWarning: use lock.release instead of del lock
+  locker = self.testlock()
+abort: repository is unrelated
 % issue1719: inotify and mq
 % inserve
 ? hg.pid

In crew-stable: http://hg.intevation.org/mercurial/crew-stable/rev/f47c0881b16e

As there was no activity, I went ahead and emailed a patch today, using
Simon's first suggestion ("let's recompute the dirstate data").

We can perhaps do better than a simple dirstate recomputation (?), but for
now, it does not make sense to leave this bug live, as we have a working
solution.

The last activity on this that I've heard of was
http://selenic.com/pipermail/mercurial-devel/2009-August/015017.html

Delegating the status calls to the dirstate (bypass inotify) when the
dirstate is dirty looks good to me.

What was the status of this, wasn't a simple "let's recompute the dirstate 
data" good enough?

thanks!

I am creating this issue to supersede issue1810 and issue1719.

Those two issues arise in different contexts, but the source of the problem
is the very same: accessing dirstate when it's dirty, and simon's is already
working on a patch.

I'm adding a patch containing merged tests and their corresponding outputs.