> -----Original Message----- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: donderdag 1 juli 2010 11:34 > To: Alan Barrett > Cc: dev@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 svn_client_cleanup(). 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 svn_client_ctx_t. Bert