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