Subversion跨Windows Server迁移及版本升级全流程咨询

Hey there, I’ve helped with several large SVN migrations between Windows Server versions, so let’s tackle your questions clearly and practically:

Windows Server 2012 and 2016 work seamlessly with all recent stable Subversion releases. Your current SVN 2.7.14 is quite outdated—I’d recommend going with the latest stable version (like 1.14.x or 1.15.x) since these versions offer better performance, security patches, and full compatibility with older repository formats.

You can grab official Windows installers directly from the Apache Subversion project; they run perfectly on 2012/2016 and are fully backward-compatible with your existing 2.7.14 repository, so you won’t hit format-related roadblocks.

Before you start moving anything, these steps are non-negotiable to avoid data loss or downtime:

• Double-down on backups: Create two separate backups of your entire repository:
  1. A full revision dump using svnadmin dump C:\path\to\your\repo > repo_full_backup.dump (this captures every commit history).
  2. A file-system level copy of the entire repo folder (including conf, hooks, and your custom replication scripts)—this is a safety net if the dump/restore process hits snags.
• Validate your hooks and scripts: Your pre/post-commit hooks and auto-replication scripts were built for 2008 R2. Check for:
  • Hardcoded paths that will change on the new server.
  • Dependencies on 2008-specific tools or environment variables (e.g., older xcopy flags, UAC permission quirks).
  • Test the scripts on the new server in a staging environment first to ensure they run without errors.
• Check repository health: Run svnadmin verify C:\path\to\your\repo on the old server. This scans for corrupted revisions or missing data—fix any issues now instead of migrating broken data.
• Plan a maintenance window: Since your repo is large, schedule a time where users won’t be committing changes. Even if you do a live migration, pausing writes during the final cutover ensures no data is lost.
• Confirm system resources: The new server needs enough disk space (at least 20% more than your current repo size for temporary files) and memory to handle the restore process smoothly.

Follow this sequence to keep things smooth:

Step 1: Set up the new server #

• Install Windows Server 2012/2016 and configure basic settings (network, firewall rules—open port 3690 for SVNserve, or 80/443 if using HTTP(S)).
• Install your chosen SVN Server version. Stick with default settings unless you need a specific repository directory structure.

Step 2: Backup the old repository #

• Notify users to pause commits, then stop the SVN service on the old server.
• Run the full dump command mentioned earlier: svnadmin dump C:\old\repo\path > repo_full_dump.dump. For extra-large repos, split the dump into smaller files using PowerShell (e.g., Get-Content repo_full_dump.dump | Split-File -Size 100MB -Path "repo_dump_part_").
• Copy the dump file(s), the entire conf folder (contains user auth/permissions), hooks folder (your scripts), and your auto-replication scripts to the new server.

Step 3: Restore to the new server #

• Create an empty repo on the new server: svnadmin create C:\new\repo\path.
• Load the dump file: svnadmin load C:\new\repo\path < repo_full_dump.dump. If you split the dump, load parts in order (e.g., svnadmin load C:\new\repo\path < repo_dump_part_001).
• Overwrite the new repo’s conf folder with the old one’s files (update paths in svnserve.conf if your repo directory changed).
• Copy your hook scripts to the new repo’s hooks folder, update any hardcoded paths, and ensure the scripts have proper permissions (on Windows, this means the service account running SVN has read/write access to the scripts and target directories).

Step 4: Test thoroughly #

• Start the SVN service on the new server.
• Test basic functionality:
  • Checkout the repo with a client: svn checkout svn://new-server-ip/repo.
  • Make a test commit to trigger pre/post-commit hooks and verify they work as expected.
  • Confirm your auto-replication script copies files to the correct directory.
  • Validate user permissions to ensure access matches the old server.

Step 5: Cut over to the new server #

• Notify users to update their SVN working copies to point to the new server address (use svn switch --relocate old-url new-url if they don’t want to re-checkout).
• Stop the old SVN service permanently to prevent accidental commits.
• Monitor the new server for a few hours to ensure everything runs smoothly.

Step 6: Post-migration cleanup #

• Keep the old repo backups for at least a week (or until you’re 100% confident no issues exist).
• Monitor disk usage and performance on the new server—large repos can benefit from periodic svnadmin cleanup to optimize storage.

内容的提问来源于stack exchange，提问作者saran