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_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:42:22 CEST