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:a...@cequrux.com] > > Sent: Thursday, July 01, 2010 8:26 AM > > To: dev@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. > >
