[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_sleep_for_timestamps

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-11-30 18:48:34 CET

Julian Foad <julianfoad@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 <gareth.mccaughan@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
Received on Sun Nov 30 18:49:10 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.