Gareth McCaughan <gareth.mccaughan@pobox.com> writes:
> Suppose I do this:
>
> $ for x in 1 2 3 4 5 6 7 8 9; do touch foo.$x; done
> $ svn add foo.*
> $ svn revert foo.*
>
> Then each reversion takes ~ 1 second of elapsed time.
[...]
> The documentation for svn_sleep_for_timestamps says:
>
> /** Sleep until the next second, to ensure that any files modified
> * after we exit have a different timestamp than the one we recorded.
> */
>
> I'm not sure I understand this, but if I'm guessing the meaning
> correctly then
>
> 1 surely this offers no protection against modifications
> happening asynchronously (e.g., by another process owned by the
> same user)
That's correct.
> 2 if that isn't a concern -- e.g., because we expect each WC
> to be being tweaked by at most one process at any time --
> then it would be nice if the reason were documented
Ah. Fair enough. The reason was that scripts running over working
copies could be (have been) fast enough to get a timestamp tweak and a
modification into the same clock slot (whatever the granularity).
That's why we added the sleep()s. If you wanna formulate a patch that
adds further explanation to the docstring for
svn_sleep_for_timestamps(), that'd be great.
> 3 isn't it (just as) safe to do a single sleep when the whole
> "svn revert" command has finished running? Or, if it isn't
> (because, say, "svn revert" might misbehave when passed the
> same filename more than once if it didn't make sure of
> some strong monotonicity property), is it *really* necessary
> to sleep for an average of 0.6 seconds on every file in every
> case? (Actually, when each reversion is very quick it's an
> average of ~ 1 second on every file.)
We do sleep once per revert operation, but because you ran revert
using wildcards, each target (each expanded wildcard result) is its
own revert operation. Had you simply run 'svn revert -R .', you would
have only slept once.
> I find that I quite often revert a considerable number of files,
> separately named on the command line, in a single operation,
> and having that be (guessing...) 8x faster would be very nice.
It's too much of a burden to expect the individual client programs to
remember to sleep() for their own safety. That's why we do this down
in the core libraries. And it would be an API atrocity to add some
idiotic callback from those libraries to ask the question "Can I sleep
now?".
So it would seem that the best way to get the behavior you want is to
passing the whole target array to the core libraries and iterated over
them there instead of in the client program itself. I'm fine with
such an API change. Got patch?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 31 15:42:59 2003