svn_sleep_for_timestamps

Some questions on svn_sleep_for_timestamps, which sleeps until just after the next 1-second boundary.

What are the rules for deciding whether we need to sleep for time stamps? It seems to be generally "if we have touched any of the user's files that are under our control", and the reason is so that Subversion can use the time stamps to detect whether a file has been modified.

There are some cases in which we sleep unnecessarily: when we have explicitely set a time stamp different from "now", such as the commit time; and when an operation turns out to be a no-operation, such as "svn revert *.c" which takes at least N seconds to complete even if some or all of the N files have not been modified. We should optimise these situations sooner or later.

There appear to be cases where we fail to sleep. While wc_to_repos_copy sleeps (because it does a commit which can touch the WC), the two types of copy that copy files into the WC do not sleep. Nor do the operations beginning with "m": "move", "merge" and "mkdir". Are those operations broken, or is there some reason why they do not need to sleep?

As I recall, on a FAT file system, time stamps have 2-second resolution. On FAT file systems, should it not therefore sleep until the next 2-second boundary rather than a 1-second boundary? (Perhaps this only applied to the older version of FAT file systems is not true on the versions of FAT that we support.)

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 30 01:29:48 2003