[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Moving Repositories to New server

From: Giulio Troccoli <giulio.troccoli_at_mediatelgroup.co.uk>
Date: Tue, 26 Jul 2011 16:11:04 +0100

On 26/07/11 15:35, Phil Pinkerton wrote:
> Are there any know issues with regards to moving Repositories from one
> platform to another ?
> Will the old Repositories maintain their current SVN revision ?
> Current platform Sun Solaris 10: SVN 1.6.5
> Target platform Red Hat Enterprise 5 SVN 1.6.17 ( Subversion Edge )
> Planned steps (Creating a script for the dumps and loads as there as a
> few hundred Repositories to move.)
> (1) Freeze the repository . Take a dump of the repository.
> (2) Verify the file is dumped correctly by making sure that the last
> version dumped is the same as the one in the live repository. Also
> check the return code of the svnadmin dump command.
> (3) Copy the dump file over to the new server. Verify that the file is
> copied over correctly.
> (4) Load the dump
> (5) Verify the load.
> (6) Migrate and hook scripts or authorization files over.
> (7) Verify the scripts and configuration files work.
> (8) If you have a name for the server for accessing it. You might have
> to point the name to the new server.
> a. use switch ?
> b. or relocate ?
> (9) Unfreeze the repository.
> Questions : Switch vs relocate ?
> Effects of load into a new Subversion version ?
To minimise down-time I would suggest looking into using svnsync to
create the new repository, I think something on the following lines
should work

1. create the new repository and sync it with the master one

2. copy over the hooks and scripts

3. inform all users that the old repository is not available any longer
and any commit will not work and possibly be lost

4. lock down the master repository.
This may just be stopping Apache serving it, nothing drastic, like
removing it, is neceserry yet. Besides, it's safer to keep it just in case

5. set the new repository as master.
This involves deleting some revision properties on revision 0 that
Subversion uses to sync the repository. As the new repository will not
be synced any more these are no more necessary. Moreover, they will
prevent the repository to work as a normal one rather than a
synchronised copy.

6. inform all users to use svn switch --relocate to point their WCs to
the new repository

As you can see the old repository comes down only at step 4, and steps 5
takes only few seconds.

I used this set-up for my DR solution. I had never had the chance to use
it, but I did some testing and it seemed to work.

Received on 2011-07-26 17:11:42 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.