> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: donderdag 1 juli 2010 11:34
> To: Alan Barrett
> Cc: dev_at_subversion.apache.org
> Subject: Re: auto-upgrade of working copy
> On Thu, Jul 01, 2010 at 09:25:33AM +0200, Alan Barrett wrote:
> > On Wed, 30 Jun 2010, Greg Stein wrote:
> > > Nope. Users cannot generally downgrade their client to run a
> > > Historically, we have always auto-upgraded the working copies, even
> > > with stale logs in them.
> > >
> > > The 1.7 upgrade process is too invasive and time-consuming, so we
> > > decided to have a manual process ('svn upgrade'). But moving
> > > the intent is to continue an auto-upgrade mechanism even with stale
> > > workqueues.
> > 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".
> I have repeatedly heard similar complaints and would therefore prefer
> an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
> starting with 1.7. And I have never heard anyone asking for the auto-
> feature to be kept.
> The CLI client can print an error. GUI clients can show a window
> the user whether to run an upgrade or bail out.
Hmm... and how does a client that is build/designed against 1.5, but now
linked against 1.8 handle this?
It doesn't know how to call svn_client_upgrade() as that is only introduced
Possible fix: Maybe we should also enable upgrading from older variants of
Older clients know how to call that function.
> This does not harm people using a single client much, but helps users
> who use several clients simultaneously a lot (they don't have to get
> fresh WCs to continue getting work done).
> We could also add a configuration option to ~/.subversion/config that
> causes working copies to always be auto-upgraded, defaulting to 'off'.
And how does libsvn_wc (and especially the deprecated functions that don't
receive a wc_ctx) decide which config file it should use? Not all functions
receive the configuration that is read by svn and then posted in the
Received on 2010-07-01 13:12:02 CEST