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
Received on 2011-07-26 17:11:42 CEST