SVN迁移到另一台服务器，最直接有效的方法是使用svnadmin dump和load命令完整备份和还原仓库数据，或者通过svnadmin hotcopy实现数据同步，两种方式都能保留完整版本历史。
迁移前准备：检查与备份
在动手迁移之前，需要先确认两个环境的状态，这一步如果做不好,后续容易卡壳。
确认SVN版本和仓库结构
- 在源服务器执行
svnadmin --version，记录当前版本号，目标服务器应安装相同版本或更高版本（向前兼容，但低版本可能无法读取高版本数据）。 - 查看仓库目录结构，确认是否存在多个仓库，以及各仓库的路径，如果仓库数量较多，建议整理一个清单,方便批量操作。
- 检查仓库的权限配置文件（通常为conf/目录下的authz和passwd），以及钩子脚本（hooks/目录下的钩子文件），这些文件需要随仓库一起迁移,否则后续用户访问会出问题。
备份仓库数据
- 如果仓库正在运行，建议先使用
svnadmin hotcopy /path/to/repo /backup/repo做一个热备份，这个命令会生成一个一致性快照,适合迁移时作为源数据。 - 如果仓库体积较大，也可以直接用
svnadmin dump /path/to/repo > dumpfile生成一个完整的转储文件，该文件是文本格式，易于压缩和传输，但要注意，dump过程会消耗一定时间,且仓库越大耗时越长。
检查目标服务器环境
- 确保目标服务器已安装Subversion软件包，并拥有足够的磁盘空间，可以使用
df -h确认剩余空间是否大于源仓库数据量的1.5倍（考虑压缩和临时文件）。 - 防火墙和网络端口（默认3690）需要提前开放,以便后续客户端访问。
- 目标服务器上的SVN服务可以暂时不启动,等导入数据后再配置。
svn迁移到另一台服务器的核心步骤（dump/load方式）
这是最经典、兼容性最好的迁移方式，支持跨操作系统、跨文件系统,甚至跨大版本迁移。
生成完整转储文件
在源服务器上执行：
svnadmin dump /svn/repos/myproject > myproject.dump
- 如果仓库包含很多修订版本，可以加上
--incremental参数进行增量备份,但首次迁移建议全量dump。 - 输出文件会比较大，可以使用gzip压缩：
svnadmin dump /svn/repos/myproject | gzip > myproject.dump.gz,传输时节省带宽。
传输转储文件到目标服务器
使用scp、rsync或网络共享等方式将文件复制到目标服务器。
scp myproject.dump.gz user@目标IP:/tmp/- 传输完成后，在目标服务器上解压：
gunzip myproject.dump.gz。
在目标服务器上创建新仓库
svnadmin create /svn/repos/myproject- 注意仓库路径的权限，确保SVN运行用户（如www-data或svnuser）有读写权限。
- 可以使用
svnadmin create --pre-1.4-compatible等参数指定兼容性,但通常使用默认参数即可。
导入转储数据
svnadmin load /svn/repos/myproject < myproject.dump- 加载过程会逐条重建修订版本，如果仓库版本数很多，建议使用
nohup运行,避免终端断开中断。 - 加载完成后，用
svnadmin verify /svn/repos/myproject检查仓库完整性。
恢复权限和钩子脚本
- 复制源服务器的conf/authz和conf/passwd文件到目标仓库的conf目录下，注意文件权限,确保SVN服务能读取。
- 复制hooks/目录下的钩子脚本，并根据目标服务器环境调整路径（如python、perl的解释器路径）。
更高效的迁移方式：svnadmin hotcopy
如果源服务器和目标服务器之间网络带宽足够，且文件系统类型一致（比如都是Linux ext4）,使用hotcopy结合rsync可以实现更快的同步。
热拷贝并同步
- 在源服务器上执行
svnadmin hotcopy /svn/repos /tmp/repos-copy,得到一个完整且一致的副本。 - 使用rsync将该副本传输到目标服务器：
rsync -avz /tmp/repos-copy/ user@目标IP:/svn/repos/。 - 在目标服务器上，直接将该副本作为仓库目录，无需加载，但需要确保路径正确,并调整配置文件中的仓库路径。
适用场景
- 仓库体积较大（几十GB以上），且源和目标服务器在同一局域网内，rsync可以只传输增量部分,后续增量同步效率很高。
- 需要迁移多个仓库，hotcopy可以一次性复制整个仓库集合,再通过脚本批量调整。
| 迁移方法 | 适合场景 | 优点 | 缺点 |
|---|---|---|---|
| dump/load | 跨平台、跨版本、小仓库 | 兼容性好，数据可压缩 | 大型仓库耗时长，占用磁盘空间 |
| hotcopy+rsync | 同平台、大仓库、局域网 | 速度快，支持增量同步 | 需要一致的文件系统，跨平台可能有问题 |
svn数据迁移注意事项
迁移过程中有几个容易忽略的细节,处理不好会导致客户端无法正常使用。
用户权限与认证
- 如果源服务器使用了SASL或LDAP认证，需要确认目标服务器是否支持同样的认证方式，使用简单密码文件（passwd）迁移最省事,直接复制文件即可。
- authz文件中的路径写法需要与仓库路径匹配，如果目标服务器上仓库路径不同，需要修改authz中的路径映射（例如
[myproject:/]要对应实际的仓库名）。
客户端relocation
- 迁移完成后，所有客户端的工作副本（working copy）需要切换到新的服务器地址，使用
svn switch --relocate命令，svn switch --relocate http://旧服务器/repo http://新服务器/repo - 如果客户端数量较多，建议编写脚本批量执行,或者通过邮件通知用户自行relocate。
钩子脚本的兼容性
- 钩子脚本中可能包含硬编码路径（如邮件通知脚本中的服务器地址）,需要逐一更新。
- 确保钩子脚本有可执行权限，且解释器（如bash、python）在目标服务器上已安装。
迁移后验证与文件完整性检查
导入数据后，不能只凭无报错就认为迁移成功,需要做几项验证。
仓库完整性验证
- 使用
svnadmin verify /svn/repos/myproject，该命令会扫描所有修订版本，检查是否存在损坏，如果输出错误信息,需要重新dump或加载。 - 对于大型仓库，验证过程可能花费数小时,但这是确保数据安全的关键步骤。
客户端检出与日志检查
- 在目标服务器本地或远程客户端，执行
svn checkout http://新服务器/repo /tmp/test,看是否能完整检出所有文件。 - 使用
svn log -l 10查看最近10条日志，确认提交记录、作者、日期是否与源服务器一致。 - 随机查看几个目录下的文件,比较内容是否与源仓库一致。
性能测试
- 迁移完成后，建议进行简单的并发读写测试，确认目标服务器性能是否满足需求，让多个客户端同时执行
svn up和svn commit,观察响应时间。
常见问题与解答
svn迁移到另一台服务器时版本号会变吗？
不会，使用dump/load或hotcopy迁移，仓库的修订版本号（revision number）会完全保留，客户端relocate后，工作副本中的版本号也不需要重建,直接与新服务器保持一致。
如何迁移多个仓库到新服务器？
可以写一个脚本，遍历所有仓库目录，逐一执行dump或hotcopy，如果使用dump方式，每个仓库生成一个独立的dump文件，再在目标服务器上批量创建仓库并load，如果使用hotcopy，可以一次性复制整个仓库目录,但需要确保目标服务器上每个仓库的路径配置正确。
迁移到不同操作系统（如Windows到Linux）需要注意什么？
主要关注文件路径分隔符和权限设置，Windows下仓库路径使用反斜杠，Linux下使用正斜杠，但SVN内部存储是基于跨平台的，所以dump/load方式可以完美迁移，直接复制仓库文件（hotcopy）时，需要确保文件换行符和权限位正确，通常建议在Linux目标服务器上使用chmod -R 755和chown -R svn:svn调整权限，钩子脚本的扩展名也需要调整（Windows下使用.bat，Linux下使用.sh或直接去掉扩展名）。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/598715.html
