[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: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 1 Jul 2010 13:10:37 +0200

> -----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
> cleanup.
> > > 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
> forward,
> > > 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-
> upgrade
> feature to be kept.
> The CLI client can print an error. GUI clients can show a window
> prompting
> 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
in 1.7.

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

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