dirstate hooks

[Adrian Buehlmann]

On 17.05.2009 17:31, Steve Borho wrote:
> TortoiseHG has introduced C++ explorer extensions on it's development
> branch.  We've found that directly reading the dirstate cache is an
> order of magnitude faster than running repo.status(), and more
> importantly removing the Python shell extensions fixes a large number
> of interoperability problems that have plagued the project from the
> beginning.
> 
> Reading the dirstate file directly has some drawbacks that we would
> like to try to at least partially work around.  In particular, the 'n'
> or 'not-set' state which occurs when a file was last modified within a
> second of it's being scanned.  It happens very consistently after
> clone and update operations.  I would like to be able to introduce a
> hook or other UI configuration so that TortoiseHg can opt in for a
> delay here to wait for the second hand of the system clock to roll
> over before continuing.

See also af3f26b6bba4, which introduced config option [ui] 'limit'
(the granularity of file times, default is 1 second).

Maybe we could introduce a new config option [ui] 'dirstatewait'?
With a default of False. If set to True, Mercurial should wait
for 'limit' seconds (maximum), such that there are no 'unset'
entries left in .hg/dirstate.

The CuteHg project and the Eclipse plugin would probably benefit
from this as well.

BTW, state 'n' is just the 'normal' state. "unset" entries have
no modification time info (see example output of 'hg debugstate'
on DirState in the wiki [1]).

> I believe many of our users would be willing to take the potential 1
> second delay here in order to always have consistent file overlays
> (and the ones that aren't should be able to disable the feature).
> 
> And lastly, I would like to be able to set a hook for whenever the
> dirstate changes, so that we can notify explorer to refresh it's open
> windows in that repository.  Unfortunately, hook seems to be a repo
> functionality and dirstate is nicely layered away from the repo.
> (we've been doing this manually after calling mercurial commands, but
> it is error prone and doesn't work at all with command line hg).
> 
> I'm mostly looking for feedback on the best way to approach both issues.

I've been looking at the 'update' hook. We can't use that, because
when this hook is fired, repo.status() returns the files that were
changed by the update (or merge).

I think we need a new hook -- let's call it 'postupdate'. When postupdate
is fired, repo.status() should return the status of the working tree
that exists _after_ the update (or merge) is completed -- not what
changed (as for the 'update' hook).

[1] http://www.selenic.com/mercurial/wiki/DirState