Around about 01/02/11 18:00, Mark Phippard typed ...
I created a folder with 5001 files in it ... maybe that is not enough?
I think the issue is to do with properties, so you'd have to make sure all those files have props. (we use autoprops for mime-type/eol-style/header-expansion).
IIRC, upon checkout the file is copied to .svn/tmp/text-base using a version of the file name, but the associated prop-base file which the metadata are put into is called tempfileXXX.tmp, with an ever-increasing XXX, the calculation of which (via file probing) gives the logarithmic slow down.
I don't know why it does that (or if I'm mis-interpreting) as the final prop-base files are named after the source file and not a temp file name.
Certainly, I've got 1.6.15 on both Linux and Windows and they both do this on an NTFS drive (it was something like 85 minutes to check out our ~5200 files [may be 6200, can't remember]). Linux did it to ext3 in a little over a minute.
I have since compiled up the latest 1.6.x branch, and patched svn_io_open_unique_file3() to not call svn_io_open_uniquely_named() with 'tempfile.tmp', & instead I cut'n'paste svn_io_open_uniquely_named(), replacing the 1-99999 loop with 1-MAX_RAND and used the output of rand() in the filename to try.
This gave me a few seconds improvement in Linux, and a drastically improved 5 minutes in Windows (possibly only now slower as it was writing to a network mapped drive).
I couldn't use the version from trunk/1.7 as it differs too much. I will try to submit the patch for someone's perusal at some point, but I couldn't properly test is as for some reason my build of svn out of 1.6.x svn (even before modifying it) fails 'make check': all the tests pass, but I get a load of XFAIL lines I don't understand.
AFAICT, the XFAILs I get after my patch are the same as before, but it's not the warm PASS feeling I was hoping for.
-- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit
