Migrating Subversion Repositories across servers

Question

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 wer

Answer 1

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.

Answer 2

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.

Answer 3

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.