Hey Larry!
Good to hear from you. Been quite a while :-P
Yes, the delay is there to deal with filesystem timestamp resolution
issues. I don't recall the specifics of *why*, but Bad Things can
happen if a filesystem doesn't have enough resolution.
You can disable the delay with:
$ export SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS=yes
before you run your update/export/whatever processes.
I would also like to point out that svn 1.7 will have a new tool named
"svnrdump" that produces an svn dumpfile from a *remote* repository.
If you guys have tools to process dump files, then svnrdump could be
very helpful for those who don't have server/admin access to produce a
dumpfile. It is pretty efficient tool, and was originally inspired as
a way to get a dumpfile for a fast-import into Git.
The 1.7 release is still a few months away, but if you're gung-ho,
then you could build it from trunk and deploy it for your data export
process.
Cheers,
-g
On Sun, Nov 21, 2010 at 13:05, Larry McVoy <lm_at_bitmover.com> wrote:
> Hi hackers,
>
> We've got a customer that needs to move some data out of SVN and we wrote a
> tool for them to do so.
>
> Unfortunately, that tool is slow because svn update seems to artificially
> slow itself down, I've straced it and at the end there is a select() that
> waits until one second has passed by. I'm guessing there is some sort of
> transaction log that doesn't want to be updated more often than that?
>
> Before I waste more time (spent a half hour in the sources this morning
> between dealing with kids), is there a flag to turn this off? With it
> on it makes SVN appear to be 12x slower than BK and I know it's not that
> slow.
>
> Thanks,
>
> --lm
>
Received on 2010-11-22 01:59:54 CET