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

"svn revert" performance

From: Gareth McCaughan <gareth.mccaughan_at_pobox.com>
Date: 2003-10-31 12:24:02 CET

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.
Approximately no CPU time is being used. (Total of
~ 0.06s user+system.) My HD is doing approximately
10 transfers per second during this time, averaging
between 8 and 9 Kb per transfer, which doesn't sound
like it ought to take very long.

Running under gdb, interrupting and doing a backtrace
reliably yields something along these lines:

#0 0x28518acc in select () from /usr/lib/libc.so.4
#1 0x282cb8f4 in apr_sleep (t=981715) at time.c:288
#2 0x2811ea29 in svn_sleep_for_timestamps ()
    at subversion/libsvn_subr/time.c:286
#3 0x2808a77d in svn_client_revert (path=0x80632e8 "foo.4", recursive=0,
    ctx=0xbfbff878, pool=0x8071018) at subversion/libsvn_client/revert.c:112
#4 0x80509f0 in svn_cl__revert (os=0x8062050, baton=0xbfbff728,
    pool=0x8062018) at subversion/clients/cmdline/revert-cmd.c:69
#5 0x804e309 in main (argc=11, argv=0xbfbff994)
    at subversion/clients/cmdline/main.c:1160

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)

  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

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

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.

I'll understand if there's a deep necessity for this that I'm
failing to see...

Gareth McCaughan
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 31 12:25:06 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.