As pretty much an end user only of SVN;
I don't really much care - which option is the faster.
it will simply be a case of - do whichever of the tasks is the fastest way to get me back to doing my real job, writing code.
Whatever gets SVN out of my way the soonest - is the path that I will choose to go from 1.6.x to 1.7.
If the quickest route for this is;
* commit all local changes
* checkout a new copy,
so be it.
Sure I woud prefer for it to be all done, in-place - and I'd certainly prefer that the upgrade process was blisteringly fast too.
But at the end of the day;
I am using version control - because I care about the history of the repository's contents.
The integrity of the repo is the only "real" concern that I have,
The time it takes to;
* upgrade my repository
* upgrade my server binaries
* upgrade my client
* upgrade my working copy
Is simply going to be, the time it takes to perform those tasks, however long that might be.
Gavin "Beau" Baumanis
On 08/06/2011, at 5:22 AM, 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"
> "1.7 performance requirements for release"
> "WCNG - Upgrading working copies"
> 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
> 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)
> 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?
>  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
> TimeThis : Command Line : svn co -q
> 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:
> 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-08 01:39:23 CEST