On Fri, Jul 08, 2011 at 01:56:07PM +1000, Tony Butt wrote: > On Fri, 2011-07-08 at 03:58 +0300, Daniel Shahaf wrote: > > Tony Butt wrote on Fri, Jul 08, 2011 at 10:41:43 +1000: > > > Probably don't want to do that. > > > We are in a commercial environment, with some 20 developers relying on > > > subversion - not the time for an alpha release. > > > > > > > I wasn't suggesting that you upgrade your production server! > I didn't really think you would be :-) > > > > Just that you install the alpha in a test environment to see if it > > improves the situation for you. (or if there is anything you see that > > requires modification /before/ the release --- before compatibility > > promises apply --- as in eg issue #3952) > > > My available test server also syncs the production repository to itself > as a hot spare. I am probably brave enough to install 1.7.0-alpha3 on > that, so long as there are no issues syncing from 1.6.17 to 1.7.0
Hi Tony, Doing pre-release testing is a great service to the community. For us, it is a lot easier to handle problems before the release, and we can respond to problem reports a lot quicker. After release we are bound by compatibility guarantees that sometimes make bug fixing a little more painful. And you might have to wait for weeks for enough fixes to accumulate before a new patch release is issued that addresses your particular problem. You will likely upgrade your setup to Subversion 1.7 eventually. Any problems that show up which are specific to your setup will have to be dealt with at that point. It's easier to spot and fix problems now, while you're not running 1.7 in production and while we're still moving towards the 1.7.0 release. One good way of testing is to make a somewhat recent (say, one week old) repository snapshot available though a 1.7 server reachable at a temporary URL. Then ask a few developers to put aside half an hour to try to use this temporary server (with fresh working copies) and perform whatever steps they performed on the real server again on this new server (checkout, update, commit, merge, ...). The developers can use either 1.6 or 1.7 clients to do this. Both should "just work". You don't need a separate server machine if you can install Subversion 1.6 and Subversion 1.7 in parallel (this may not be easy depending on what kind of package management you are using). You can start the 1.7 server on a different port (e.g. 8080), and point it at the repository snapshot which can be located anywhere in the machine's filesystem. This way your production setup is not affected at all, apart from sharing CPU and memory resources with the test setup. But if you cannot install 1.6 and 1.7 at the same time, you should use a separate machine for testing. Please do not install and use 1.7 on a Subversion server which you rely on, for whatever purpose (even for backup), just yet. You can get binaries of Subversion 1.7 alpha releases for some platforms here: http://subversion.apache.org/packages.html#pre-release Thanks! (And if you cannot test now, that's fine -- it just means you will get to test later, when it will be less convenient ;)
