Just a thought: is the upgrade time linear with WC size? If so, I say "good enough", if much worse than linear, probably not good enough.
- Julian On Tue, 2011-06-07 at 15:22 -0400, Paul Burba wrote: > 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.)
