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

Re: svn commit: r1139766 - /subversion/trunk/subversion/svn/main.c

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 27 Jun 2011 13:13:25 +0200

On Mon, Jun 27, 2011 at 11:34:13AM +0100, Philip Martin wrote:
> stsp_at_apache.org writes:
>
> > Author: stsp
> > Date: Sun Jun 26 12:28:28 2011
> > New Revision: 1139766
> >
> > URL: http://svn.apache.org/viewvc?rev=1139766&view=rev
> > Log:
> > * subversion/svn/main.c
> > (svn_cl__cmd_table): In the help text for 'svn upgrade', explain that
> > the upgrade preserves local modifications, and that an upgrade from
> > 1.6 to 1.7 takes more time than a new checkout.
> >
> > Modified:
> > subversion/trunk/subversion/svn/main.c
> >
> > Modified: subversion/trunk/subversion/svn/main.c
> > URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/svn/main.c?rev=1139766&r1=1139765&r2=1139766&view=diff
> > ==============================================================================
> > --- subversion/trunk/subversion/svn/main.c (original)
> > +++ subversion/trunk/subversion/svn/main.c Sun Jun 26 12:28:28 2011
> > @@ -1380,7 +1380,13 @@ const svn_opt_subcommand_desc2_t svn_cl_
> >
> > { "upgrade", svn_cl__upgrade, {0}, N_
> > ("Upgrade the metadata storage format for a working copy.\n"
> > - "usage: upgrade WCPATH...\n"),
> > + "usage: upgrade WCPATH...\n"
> > + "\n"
> > + " Local modifications are preserved.\n"
> > + "\n"
> > + " Note: Upgrading a working copy from the format used in Subversion 1.6\n"
> > + " to the format used in Subversion 1.7 takes much more time than checking\n"
> > + " out a new working copy with the 1.7 client.\n"),
>
> I disagree.
>
> Upgrade requires more disk IO but requires significantly less network IO
> and uses marginally less CPU. Checkout is likely to be faster when disk
> IO is the limiting factor, but if network IO is the limiting factor then
> checkout could be significantly slower.

When I upgraded a 1.6.x working copy of 2GB size, it took more than one hour.
I eventually just aborted the upgrade. A checkout completes within
a couple of minutes.

The repository is remote and the bottleneck should be my 16MB/s downstream
link (the server is connected to my ISP via the berlin internet exchange
at 100Mbit/s). So based on what you're saying I should be seeing a much
better upgrade vs. checkout ratio.

Link to the repository: http://svn.dslinux.org/svn/trunk

svn also seemed to spend more and more time hogging the CPU as the upgrade
progressed. Note: I have not profiled this, it is all based on what I
perceived while waiting for the upgrade to complete, and I kept box getting
more and more impatiant. I'd be willing to repeat this experiment with a
profiled build.
Received on 2011-06-27 13:14:07 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.