We've touched upon the performance of 'svn upgrade' vs. a fresh
checkout a few times:
"1.7 timing tests: update great, checkout needs work, upgrade horrible"
http://svn.haxx.se/dev/archive-2010-12/0161.shtml
"1.7 performance requirements for release"
http://svn.haxx.se/dev/archive-2010-12/0232.shtml
"WCNG - Upgrading working copies"
http://svn.haxx.se/dev/archive-2010-11/0503.shtml
We don't have anything specific to this on the roadmap beyond
(possibly?) taking a look at svn_wc_upgrade as part of the API
Performance Analysis. The only relevant issue I saw was
http://subversion.tigris.org/issues/show_bug.cgi?id=3785 "fix
performance of 'svn upgrade' text-base handling" and that is marked as
fixed.
I ran a series of simple comparisons today, checking out the 1.6.17
tag vs. upgrading a 1.6 WC of the same. The upgrade was about twice
as slow (yes obviously there are a lot of moving parts here and making
a comparison between a local operation and one over the network is
inherently dubious, but it's something):
svn co -q https://svn.apache.org/repos/asf/subversion/tags/1.6.17
(3,214 files, 452 directories excluding .svn folders)
Using trunk_at_1133033 with ra_neon (ra_serf fails[1])
Elapsed Time : 00:00:54.493
Elapsed Time : 00:00:52.994
Elapsed Time : 00:00:48.076
Elapsed Time : 00:00:48.461
Elapsed Time : 00:00:52.306
Elapsed Time : 00:00:41.084
Elapsed Time : 00:00:52.210
Elapsed Time : 00:01:14.680
Elapsed Time : 00:01:29.557
Elapsed Time : 00:01:33.237
Average time : 00:01:00.710
svn upgrade -q
FWIW: WCs checked out with 1.6.17 client
Upgrade done with trunk_at_1133033
Elapsed Time : 00:02:03.156
Elapsed Time : 00:02:45.311
Elapsed Time : 00:02:39.375
Elapsed Time : 00:01:32.864
Elapsed Time : 00:01:03.170
Elapsed Time : 00:01:27.547
Elapsed Time : 00:00:00.064
Elapsed Time : 00:01:57.378
Elapsed Time : 00:01:52.263
Elapsed Time : 00:02:39.548
Elapsed Time : 00:02:47.763
Average Time: 00:02:04.844
A few questions:
1) Any other issues or threads of relevance I missed?
2) Is anyone actively looking at this?
3) Is there a general sense that upgrade performance is currently
adequate? Do we really care if upgrade is slower than a checkout, as
long as it is in the ballpark? After all, this is a one-and-done
operation for most users.
4) When we release 1.7 what will our default recommendation be
(assuming the user has no local changes)? Upgrade or fresh checkout?
I'm assuming the former, but are we open to the latter if performance
is a problem?
Paul
[1] Haven't looked into this yet:
C:\SVN\sandbox\1.7-Performance-Test\upgrade-vs-checkout>timethis svn
co -q https://svn.apache.org/repos/asf/subversion/tags/1.6.17
1.6.17-serf-WC1
TimeThis : Command Line : svn co -q
https://svn.apache.org/repos/asf/subversion/tags/1.6.17
1.6.17-serf-WC1
TimeThis : Start Time : Tue Jun 07 14:22:16 2011
svn: E620019: Error retrieving REPORT (620019): APR does not
understand this error code
This application has halted due to an unexpected error.
A crash report and minidump file were saved to disk, you can find them here:
C:\Users\pburba\AppData\Local\Temp\svn-crash-log20110607142236.log
C:\Users\pburba\AppData\Local\Temp\svn-crash-log20110607142236.dmp
Please send the log file to users_at_subversion.apache.org to help us analyze
and solve this problem.
NOTE: The crash report and minidump files can contain some sensitive information
(filenames, partial file content, usernames and passwords etc.)
Received on 2011-06-07 21:23:21 CEST