Around about 08/02/11 10:01, Neil Bird typed ...
> Around about 08/02/11 09:03, Daniel Shahaf typed ...
>> Thanks. However, to clarify, I'm not specifically interested in the
>> "give us N revisions" form; I'm just interested in seeing a coherent
>> patch at the end, and wanted to ensure you haven't forgotten that in
>> depth of coding.
>
> It's just going to take longer that I planned :)
OK, I tried back-porting (svn merge) actual trunk revisions to get a
working fix in place, but I stopped when I hit 7 of them (just for this one
change) and knew (by the volume of conflicts I was having to patch) that it
was a no-goer.
Even if I had got it compiling and working, there would have been so many
tertiary changes that it would have been difficult to prove that it wasn't
breaking more than it fixed (there are an awful lot of secondary & important
fixes in trunk relating to the initial re-working; I'd have almost
certainly missed one).
All that added to the fact that the revision numbers seem to have all
changed (the move from Tigris to Apache?), so even when the comments *do*
say that they're fixing blah from rev. xxx, the xxx is wrong.
So, I'm going back to my initial change. It's not terribly elegant, but
it is at least clean, does the job, and passes the tests.
Just to re-iterate, what I've done is change svn_io_open_unique_file3()
so that instead of just calling svn_io_open_uniquely_named() it is in fact a
verbatim copy of svn_io_open_uniquely_named(), except that it uses rand()
(after a fashion) to generate iterative temporary file names instead of
counting from 1.
This time, I believe I have catered for the case where RAND_MAX is only
32767 (my Windows at least) without being OS-specific. I have tested it on
Linux on both ext3 and onto a shared NTFS drive (which used to exhibit the
fault).
I have not compiled it for Windows (I don't have a Windows subversion
build environment), but I have compiled both sides of the ifdef I added.
I'll include the latest patch here, and put it on the bug entry for
posterity as well.
If you're happy with it, great, if not, well, so be it.
[[[
Fix issue #3719: prevent logarithmic slow down when checking out large
directories onto Windows NTFS
* subversion/libsvn_subr/io.c
svn_io_open_unique_file3: don't call svn_io_open_uniquely_named(), but
instead use a copy of that routine that uses rand() to get the next
potential free number instead if simply incrementing, minimising clashes on
repeated calls.
]]]
--
[neil_at_fnx ~]# rm -f .signature
[neil_at_fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil_at_fnx ~]# exit
Received on 2011-03-01 16:13:17 CET