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.

Giulio

Reply via email to