svn_sleep_for_timestamps

[Julian Foad <ju...@btopenworld.com>]

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

Re: svn_sleep_for_timestamps

[Philip Martin <ph...@codematters.co.uk>]

Julian Foad <ju...@btopenworld.com> writes:

> What are the rules for deciding whether we need to sleep for time
> stamps?

We need to sleep if the entries file is updated to set either the
text-time or prop-time to indicate that the working copy is unmodifed.

> 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.

Gareth McCaughan <ga...@pobox.com> submitted a patch for
svn revert on Nov 3 (after a couple of revisions).  It looked OK but I
haven't got round to testing/committing it, feel free to do it.

> 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

merge and mkdir don't need to sleep as they don't set text/prop-time.
Do the move/copy operations set the timestamps?  I seem to recall that
copy has some inconsistencies about it's handling of text/prop-base.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org