13

We're in the process of moving servers and one of the last items is moving over the svn repositories.

There are about 10 gigs of various svn repositories. They were created using this command: svnadmin create --fs-type fsfs

Server A(original) has svn 1.4 while Server B(target) has svn 1.6.

My thought was to use rsync to migrate the whole set of repositories (they are all in 1 folder on the server), but I am worried that some things might either not get migrated or I need special switches for rsync for this to work.

Most online tutorials only talk about moving 1 repository at a time, for example using svnadmin hotcopy, but I need to move about 100 or so all together. Is this the right way to go about it?

bahrep
  • 29,961
  • 12
  • 103
  • 150
Totomobile
  • 663
  • 2
  • 8
  • 19

3 Answers3

16

Subversion's FSFS is pretty stable on doing copies and movements, even across different OSes. While mliebelt is correct about doing it via dump reload, it takes ages to move 10 GB!

That's why I would recommend the following procedure:

  1. Copy the repositories via filesystem to new server.
    e.g. $ scp -r /var/repos/ user@newServer:repos/

  2. Do an $ svnadmin upgrade to do an update on repository for 1.6 (this is optional, but highly recommended if you want to use 1.5/1.6 features like merge tracking, sparse checkouts, etc.)

  3. Do an $ svnadmin verify on each repository to verify all revisions are okay (You can do this on already running server).

By this procedure you need probably 10 to 100 times less time:

e.g. for dumping a repository it takes usually approx 1 GB per hour (largely depending on HD-speed), the dump files are much bigger than the repositories(in SVN 1.4!) So you have to move the larger file to the new server and do there an dump-load which also takes approx 1 hrs / GB. Compare this to a filesystem copy which usually is only limited by network connection (100 mbit approx. 10 MB / sec) or HD (approx 100 MB/sec), if you have GBit-LAN.

Yes Barry
  • 9,514
  • 5
  • 50
  • 69
Peter Parker
  • 29,093
  • 5
  • 52
  • 80
  • 2
    This is what I ended up doing, just using plain rsync! First I had to setup the svn user/group. After the move I verified that the repositories are in tact using svnadmin verify. And finally, I had to edit the /etc/init.d/svnserve script to point to the proper directory. All seems to work now! (Just want to add that all timestamps and user/group permissions were preserved) – Totomobile Oct 06 '11 at 19:14
  • I did this too. I'll admit I was a bit apprehensive thinking it wouldn't work for some reason because our old version of SVN was 1.2, the new server has SVN 1.6. Still, this worked for me! Did exactly as @Peter Parker suggested as far as `svnadmin upgrade/verify` is concerned. – Yes Barry Oct 06 '12 at 02:33
3

For more info on svnadmin dump and svnadmin load for svn 1.6 see here. It offers some discussion on dump and load, as well as options like --deltas, --incremental, and others.

Also, be warned that if you do a straight copy and svnadmin upgrade you save time, but the repository state may not be optimal. From the svnadmin help :

svnadmin help upgrade

usage: svnadmin upgrade REPOS_PATH

Upgrade the repository located at REPOS_PATH to the latest supported schema version.

This functionality is provided as a convenience for repository administrators who wish to make use of new Subversion functionality without having to undertake a potentially costly full repository dump and load operation. As such, the upgrade performs only the minimum amount of work needed to accomplish this while still maintaining the integrity of the repository. It does not guarantee the most optimized repository state as a dump and subsequent load would.

Bizmarck
  • 2,663
  • 2
  • 33
  • 48
3

First of all, I am not a Subversion administrator, but I work a lot with them. So don't trust my words only, check other sources as well.

My experience over the last 5 years was:

  • To move Subversion repositories, you should use the Subversion admin tools dump and load. They are written just for that job.
  • dump and load check additionally that everything is ok. By using them, you get additional "insurance" that everything moved ok.
  • We have never migrated over 2 major versions, but moved from one major version to the next. You should at least check, that migration from 1.4.x to 1.6.x is supported. Often the new server version support the direct previous version, and supports the migration. So perhaps you have to do the migration for each repository twice.
  • You may work on the old repositories as long as they are moving, because subversion allows you to add later newer revisions.
  • Because all can be done by command line, you may automate most of it, and the subversion admins only have to check that everything has worked well.

So, yes, I would recommend to move one repository after each other.

mliebelt
  • 15,345
  • 7
  • 55
  • 92