[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Fresh checkout vs 'svn upgrade': How good is good enough?

From: Gavin Baumanis <gavinb_at_thespidernet.com>
Date: Wed, 8 Jun 2011 09:38:39 +1000

Hi Everyone,

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"
> 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-08 01:39:23 CEST

This is an archived mail posted to the Subversion Dev mailing list.