We haven't done this so far, but there's the option of allowing svn 1.8 to
write into 1.7 wc's (thus making 'svn upgrade' an optional-to-run command)
--- just as we do on the server (repos) end.
Bolstridge, Andrew wrote on Thu, 1 Jul 2010 at 11:23 -0000:
> > -----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 11:38:18 CEST