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

RE: auto-upgrade of working copy

From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Thu, 1 Jul 2010 09:23:00 +0100

> -----Original Message-----
> From: Alan Barrett [mailto:apb_at_cequrux.com]
> Sent: Thursday, July 01, 2010 8:26 AM
> To: dev_at_subversion.apache.org
> Subject: auto-upgrade of working copy
>
[snip]
> The auto-upgrade has always bothered me. I'd much prefer to have a
> command line action (e.g. "svn upgrade") to upgrade the working copy,
> and for the default behaviour to be that the client prints an error
> message suggesting that the user should run "svn upgrade".
>
> Many people use different clients in the same working copy (e.g. a
> command line client and a GUI client), and it's a pain if one client
> decides to upgrade the working copy to a format that the other client
> doesn't support.
>

Can I second this - a little while back TortoiseSVN was upgraded to svn
1.6, but AnkhSVN hadn't been recompiled to use it - as a result, working
copies could not be used by Ankh in Visual Studio, or if you wanted to
use AnkhSVN, you had to stop using the new TortoiseSVN. The guys at
AnkhSVN did issue a new version, but only after a few weeks.

Next time, I would manage a rollout of 1.7 clients now, waiting until
all clients we use had been upgraded before blindly upgrading as soon as
the new version was available. That's probably the best system to use,
and an auto-upgrade would be preferable. If the release notes gave a big
warning reminder about this, that might be the best means of managing WC
upgrades.
Received on 2010-07-01 10:23:50 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.