dirstate entries stuck in unset state
Simon Heimberg
simohe at besonet.ch
Thu Aug 13 08:44:09 UTC 2009
What about this?
---a/mercurial/dirstate.py Don Aug 13 05:58:59 2009 +0200
+++b/mercurial/dirstate.py Don Aug 13 10:19:08 2009 +0200
@@ -389,7 +389,7 @@
for f, e in self._map.iteritems():
if f in copymap:
f = "%s\0%s" % (f, copymap[f])
- if e[3] > limit and e[0] == 'n':
+ if limit < e[3] < limit + 8 * gran and e[0] == 'n':
e = (e[0], 0, -1, -1)
e = pack(_format, e[0], e[1], e[2], e[3], len(f))
write(e)
There is the risk that the file changes (without modifying the size)
when the clock time is near the modification time. (This window has a
size of gran.) This would not happen when 'hg stat' is called after
7*gran before this moment. The file state would be set to 'unset'. (Bad
English. How can I explain this exactly and nicely?)
I have chosen 8 because the minimum is 2 (+-gran) and a bigger number is
more secure. A computer can easy multiply with 8.
Am Donnerstag, den 13.08.2009, 00:11 +0200 schrieb 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
More information about the Mercurial-devel
mailing list