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 ;)
Received on 2011-07-08 11:14:34 CEST