On 6/25/07, Anne M. Hammond <email@example.com> wrote:
> We have +100 repositories on host_a (CentOS 4.3) under subversion 1.3.0-1.
> We wish to move to a new machine, host_2, running subversion 1.4.3-2
> and FC6.
> The svn migration instructions indicate to
> host_a: (as owner of repo) svnadmin dump repo > repo.dump
> host_b: svnadmin create repo
> host_b: (as owner of repo) svnadmin load repo < repo.dump
> These are all apache repositories, and the user apache is not
> allowed to login.
> Performing the above steps as root changed the ownership of the
> directories to root, and did not preserve group write permissions.
Bear in mind that this has little to do with Subversion itself - any
other program would behave the same.
> (Also note that dump and restore does not dump/restore hooks.)
I don't think there's any documentation that claims otherwise. I would
(do) treat this migration very similarly to a disaster/recovery test -
make sure that everything is backed up, have all data & other
resources needed to restore the repository to working order at hand.
> We found that you could simply create a tar file and untar it
> on the new server. Then it is available for checkout via
> the newer version of subversion.
> My question is: Why should we use dump/restore to migrate
> between versions, instead of just tarring and untarring on
> the two servers? Does dump/restore do anything special?
If you're using BDB, you have to use dump/load to migrate between
these SVN versions because of differences in the libraries.
If someone is performing an action that uses the repository while
you're tarring, you could be left with the repository in an
inconsistent state when you untar on the new host. You should at least
be using hotcopy to make a safe copy as the source of your tarfile.
But then you may be left with your repository at revision X and
someone's WC at revision X+1, and the changes made in rev. X+1 lost.
Another advantage of using dump/load is that SVN 1.4 uses an updated
delta algorithm when storing data in the repository, so space used by
your repository may decrease by a non-trivial amount by doing this. If
you use the tarball of the repo from a previous version, only
revisions after your switchover will benefit from this.
My last (ok, only) host switch I did with Subversion went:
Notify all users the day before
Shut down Apache
Update httpd.conf to eliminate access to the old repository location
svnadmin load on the new host
Update httpd.conf on the new host as appropriate
Start Apache on both hosts
Notify all users with new URL & instructions for making the switch
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Jun 26 00:58:27 2007