hash cache tuning

[Robert Collins]

I wonder if we could make our hashcache be accurate to > 3 seconds under
some circumstances.

Many trees are not shared over nfs/smb with windows; or even when shared
are not exposed as being on FAT file systems. Most file systems have 1
second, or ever greater than 1 second resolution.

So I think there are two approaches; one is to probe for whether a stat
is re-readable accurately, another is to allow users to specify how
general they want the working tree to be.

Now in general we cannot write a new file to the hashcache because we
cannot be sure its not altered post creation without re-reading it
outside the filesystems modification granularity.

However I think this is bogus: writing to files in limbo while we are
organising the tree just gives the user both pieces to take home.

So:
 we stat files as we write them to limbo.
 For the first file, we do an additional stat after making it but before
writing content, which we use to determine if we have subsecond, second,
or multisecond granularity.
 At the end of the limbo operation, some fraction of the files are
probably now older than the detected stat granularity; those we put into
the stat cache/dirstate.

Separately I think we currently discard the hash cache on commit; if so
this would be bad. I'm not sure we *do*, but think it needs checking.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070822/7a0d2f4c/attachment.pgp