Hi Philip,
thanks for the response.
Passing the deleted file means that the path based optimisations are not
available in 1.7/1.8 and so svn_io_sleep_for_timestamps sleeps for
longer.
That sounds like a fair assumption to me.
Do you see any oportunity to implement some kind of optimization for the
deletion case?
Or is it something that cannot be fixed easily?
Greets
Alex
Am 29.07.2013 19:57, schrieb Philip Martin:
Alexander Lüders <a...@entimo.de> writes:
1) svnadmin create testrepo
2) svnserve --listen-host=localhost --listen-port=4444 --root=testrepo
3) svn co svn://localhost:4444/ wc
4) create file testXXX.html in <wc>
5) svn add wc/testXXX.html
6) svn commit wc/testXXX.html
7) svn delete wc/testXXX.html
8) svn commit wc/testXXX.html
The steps 4-8 in the scenario were repeated for 30 files. The time needed for
each operation was meaned over these 30 runs.
The eigth step is taking around 11 times longer in 1.7/1.8 compared to 1.6.x.
Here are my results:
Collabnet Subversion 1.6.23-1 32bit installer:
+++++++++++++++++++++ Results ++++++++++++++++++++++++++
create: 1.930.064 nanoseconds
add: 33.922.540 nanoseconds
commitadd: 94.885.332 nanoseconds
delete: 35.964.514 nanoseconds
commitdelete: 88.359.041 nanoseconds
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Collabnet Subversion 1.7.10-1 32bit installer:
+++++++++++++++++++++ Results ++++++++++++++++++++++++++
create: 1,179,124 nanoseconds
add: 33,794,865 nanoseconds
commitadd: 91,458,958 nanoseconds
delete: 35,703,185 nanoseconds
commitdelete: 1,002,148,220 nanoseconds
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
That's about 1s which leads me to suspect svn_io_sleep_for_timestamps.
Using a debugger I can see that in 1.6 the path passed to
svn_io_sleep_for_timestamps is the parent directory which still exists
in the working copy, while in 1.8 the path is the deleted file itself.
Passing the deleted file means that the path based optimisations are not
available in 1.7/1.8 and so svn_io_sleep_for_timestamps sleeps for
longer.
