dirstate entries stuck in unset state

[Adrian Buehlmann]

(Matt suggested to bring this up on -devel, so here I am
pestering the list)

At TortoiseHg (yeah, Windows again, but read on) we've come
across a problem with files having modification times
in the future [1] (you don't want to read that reference
right now).

These cause their corresponding entry in .hg/dirstate [2] to be
stuck in the 'unset' state, until the system clock reaches
the modification time of the file, at which point in time
an update of the dirstate (side effect of e.g. 'hg status')
fixes that 'unset' entry and turns it into a regular one.

http://mercurial.selenic.com/bts/issue1790 describes detailed
steps to produce an example situation.

The problem is: TortoiseHg directly reads .hg/dirstate to show
modified/added/clean icons on files in explorer of Windows
(I'll spare you the details why we do this).

'unset' entries in .hg/dirstate lead to (almost always) wrong
'modified' icons in explorer.

At TortoiseHg we do the equivalent of 'hg status' (by using
the mercurial API) to clean up 'unset' entries in .hg/dirstate
and turn them into regular ones. We do this when we encounter
'unset' dirstate entries.

But in the case of the stuck 'unset' entries, this doesn't
work. 'hg status' fails at cleaning up an 'unset' entry, if
the system time has not yet reached the mtime of the file.

If anyone has an idea how to improve the handling of mercurial
with files having mtimes in the future, then please speak up.

[1] http://bitbucket.org/tortoisehg/stable/issue/480/
[2] http://mercurial.selenic.com/wiki/DirState