Migrate a Subversion Repository to a New Server with svnadmin Dump and Load

Desired outcome

A target Subversion repository that contains the same revisions, properties, and directory ancestry as the source. The repository UUID is preserved by default, so existing working copies can be relocated to the new server URL instead of being re-checked out. Commits through svnserve or Apache succeed with recreated authentication and hooks.

Prerequisites

• Shell access to both source and target hosts. Run commands as the system user that owns the repository files, commonly the svn service user.
• Read access to the source repository directory and write access to the target directory.
• svnadmin installed on the host performing the dump and load. Source and target versions should be compatible; a major version gap may require svnadmin upgrade after loading.
• Enough disk space for the dump file and the target repository. Dump files are uncompressed by default and can be larger than the source repository.
• An empty target repository created with svnadmin create, unless you intend to append history to an existing repository with --incremental.
• Copies of server configuration files: conf, hooks, svnserve.conf, authz, password files, or Apache access configuration. These are not included in a dump.

Procedure

1. Create a consistent copy of the live repository

Dumping a live FSFS repository while commits are in progress can capture inconsistent state. Use svnadmin hotcopy to create a point-in-time filesystem copy that is safe to dump without stopping the server.

# Run on the source host as the repository owner.
svnadmin hotcopy /var/svn/source-repo /srv/backup/source-hotcopy

Do not run svnadmin dump directly against a busy live repository.

2. Verify the hotcopy before export

svnadmin verify /srv/backup/source-hotcopy

verify reads every revision and reports corruption. Fix errors before dumping; discovering corruption after migration means redoing the transfer.

3. Create the dump file

svnadmin dump serializes revisions, properties, and change history into a portable text stream. No Subversion server needs to be running.

svnadmin dump /srv/backup/source-hotcopy > /tmp/source-repo.dump

Omit --incremental for a full dump beginning at revision 0. For large repositories, compress the dump after creation or split it by revision range. A long dump can take hours; monitor disk space because the file is uncompressed.

4. Prepare the target repository

# Run on the target host.
svnadmin create /var/svn/target-repo

Loading into a non-empty repository with overlapping revisions can fail or create duplicate history. Use an empty target unless you are deliberately appending ranges with --incremental.

5. Load the dump into the target

# Run on the target host.
svnadmin load /var/svn/target-repo < /tmp/source-repo.dump

svnadmin load replays the dump into the target. By default it preserves the repository UUID from the dump. Use --force-uuid only when you intentionally want to replace the target UUID, in which case all existing working copies must be re-checked out.

6. Upgrade the repository format if versions differ

If the target svnadmin is a newer major version than the source, run svnadmin upgrade on the loaded repository before clients use it.

svnadmin upgrade /var/svn/target-repo

This updates the FSFS format in place. Confirm that older client versions still work if your organization has not upgraded everywhere.

7. Redeploy server configuration and test access

Dumps do not transfer conf, hooks, svnserve.conf, authz, or Apache access files. Copy them manually to the target and ensure the server process can read them. Restart the server if required, then test a commit through the configured URL.

Expected checks

• Integrity: svnadmin verify /var/svn/target-repo completes without errors.
• History parity: compare HEAD revision numbers and svn log -q output for a sample path between source and target.
• Client access: perform a fresh checkout from the target URL, then run svn update and svn status to confirm working copy consistency.
• Commit path: make a test commit through svnserve or Apache to confirm authentication and hooks execute.

Recovery and limitations

If load fails partway, the target repository is left in a partially loaded state. Remove the target, recreate it with svnadmin create, and reload from the dump. Keep the hotcopy and dump until verification passes.

UUID preservation means old working copies still point to the previous server. Plan svn switch --relocate old-url new-url or fresh checkouts after cutover. If you changed the UUID, all working copies must be re-checked out.

Dump and load do not migrate custom server configuration. Missing hooks can allow unwanted commits; missing auth files can expose the repository. Major version mismatches can block older clients. Verify client compatibility after an upgrade.