Understanding dirstate.granularity

[Matt Mackall]

On Thu, 2009-09-24 at 15:02 -0400, Greg Ward wrote:
> >From reading the code, I've just stumbled across the
> dirstate.granularity config setting.  Great: setting granularity = 0
> fixes a test case I'm working on for the bfiles extension (which uses
> its own private dirstate) so it behaves deterministically.  But the
> documentation is a bit scant.  Adrian posted a patch back in May
> (http://www.selenic.com/pipermail/mercurial-devel/2009-May/012594.html)
> that would improve the matter, but it's still not entirely clear to
> me.
> 
> So... what is the purpose of dirstate.granularity?  When would you set
> it, what would you set it to, and why?  Is setting it to 0 to
> workaround a racy-looking test case appropriate?

Most filesystems have a timestamp granularity of seconds. FAT variants
have a resolution of 2 seconds. If I write a file, then record its
timestamp in the dirstate, and then modify the file all in less than a
second, the change won't be visible in the timestamp. This caused
various interesting problems in older versions of Mercurial.

Newer versions check the timestamp against the current time when writing
the dirstate and mark a file as potentially modified if it's inside the
window. Then when we next do a status check and we find the size
unchanged, we do a full check on the file and mark it clean if enough
time has passed.

-- 
http://selenic.com : development and support for Mercurial and Linux