On Tue, Mar 22, 2016 at 6:47 AM, Stefan Sperling <s...@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.
