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@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@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 us...@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.)
