Complete Guide to Subversion Repository Migration: Export and Import Strategies

Core Concepts of Subversion Repository Migration

Subversion (SVN), as a centralized version control system, requires careful handling during repository migration to ensure complete transfer of historical records, metadata, and file contents. The fundamental objective is preserving all commit history, author information, timestamps, and other metadata while maintaining repository integrity and consistency. Depending on storage backend and access permissions, migration strategies primarily fall into two categories: filesystem copying and tool-assisted export/import approaches.

Impact of Storage Backend on Migration Strategy

SVN supports two main storage backends: FSFS (Filesystem Storage) and Berkley DB. For FSFS backends (default in modern SVN versions), the simplest migration method involves direct filesystem copying of the entire repository folder. This approach works well when both source and target systems run the same SVN version and provide filesystem access. For example, on Linux systems:

cp -r /path/to/old/repository /path/to/new/repository

However, for Berkley DB backends, uncertain backend types, or cross-version migrations, direct filesystem copying may cause compatibility issues. In such cases, standardized export/import operations using svnadmin tools become necessary.

Standardized Migration Using svnadmin

The svnadmin dump command exports the entire repository into a single backup file containing all revisions and metadata. Basic syntax:

svnadmin dump /path/to/old/repository > repository_dump.svn

The dump file can be safely transferred to the target system. On the target, first create an empty repository:

svnadmin create /path/to/new/repository

Then import data using svnadmin load:

svnadmin load /path/to/new/repository < repository_dump.svn

This process replays all commit records sequentially, fully restoring repository history. Crucially, the --force-uuid option must be used to maintain consistent repository UUID; otherwise, working copies cannot switch to the new repository. Correct command:

svnadmin load --force-uuid /path/to/new/repository < repository_dump.svn

Metadata Handling and Hook Scripts

SVN uses revision properties (revprops) to store metadata such as author, date, and log messages. Proper handling of these properties during migration is essential. If revision property modifications are needed after import, pre-revprop-change and post-revprop-change hook scripts must be configured. These scripts typically reside in the repository's hooks directory and require customization based on specific needs. For example, a simple pre-revprop-change script might contain:

#!/bin/sh
REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"

# Allow all revision property changes
exit 0

Note that proper execution permissions and configuration of hook scripts are prerequisites for metadata modifications.

Migration Without Filesystem Access

When filesystem access is unavailable on either source or target systems, migration becomes more complex. One solution involves third-party tools like rsvndump, which can export repositories remotely via SVN protocol. The rsvndump workflow includes: installing dependency libraries, compiling the tool, and performing remote export. For example:

rsvndump http://svn.example.com/repo > repo_dump.svn

Then import to the new repository following standard procedures. An alternative approach involves programmatically replaying each revision using SVN log APIs, but this requires handling complex metadata synchronization issues and is generally considered a last resort.

Post-Migration Verification and Testing

After migration completion, comprehensive verification is essential to ensure data integrity. Verification steps include: checking if latest revision numbers match, validating version history of critical files, and testing commit and update operations. Basic verification commands:

svn info http://new-server/repository
svn log -l 10 http://new-server/repository
svn checkout http://new-server/repository test-working-copy

Additionally, branching, tagging, and merging operations should be tested to ensure all SVN functionalities work correctly. For team projects, coordinating all developers to switch working copy root URLs is necessary using svn switch:

svn switch --relocate http://old-server/repository http://new-server/repository

Best Practices and Considerations

When performing SVN repository migration, following best practices is recommended: first, conduct complete test migrations in non-production environments; second, ensure source repositories remain read-only during migration to prevent data inconsistency; third, backup original data as contingency; fourth, maintain detailed migration logs including timestamps, command executions, and exception handling. Special attention should be given to compatibility testing when migration involves SVN version upgrades, particularly regarding hook scripts and client tool support.

Conclusion

SVN repository migration requires careful planning and technical execution. By understanding storage backend characteristics, correctly utilizing svnadmin tools, and handling critical elements like metadata and UUIDs, successful migration can be ensured. Whether through simple filesystem copying or complex remote export/import, the core objective remains preserving historical integrity and system availability. As version control systems evolve, while SVN usage gradually declines, these technical insights retain significant value for maintaining and migrating legacy projects.