On Tue, Mar 22, 2016 at 6:47 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Mar 22, 2016 at 12:25:42AM -0400, Nico Kadel-Garcia wrote:
>> Then, when ready to switchover, make a good backup of the old system,
>> *LOCK IT* to prevent any further ocmmits, and switch services to the
>> new server. You should be able to activate a proxy or port forwarding
>> for the old service, if needed, so anyone who accidentally tries to
>> reach the old one actually gets the new one.
>
> If all deployed clients are >= 1.7, HTTP redirects from old server to the
> new server will take of moving clients over to the new server automatically:
> http://subversion.apache.org/docs/release-notes/1.7.html#http-redirects
My big concern would be anyone continuing to write to the old server,
irrelevant of redirects. Local file based Subversion access, svn_ssh
access that hasn't been disabled, and dangling svnserve based services
also need to be either never made available, or forcibly blocked, to
prevent fascinating split-brain problems.
Redirects.... well, that relies on enough control of web servers based
access, possibly including DNS, to ensure a reliable redirect.
> This only matters if the URL has changed, of course. If you can switch the
> server while keeping the URL intact, that's even better.
Yeah, *locking* the old service becomes pretty critical. If one can
ensure that *no* write occur to the new server that didn't occur on
the old server first, before the switchover happens, it's invaluable
to help prevent split-brain problems.
Received on 2016-03-23 03:59:19 CET