一、 迁移前，我们得先想明白为什么和做什么

想象一下，你要给整个公司的“文件时光机”搬个新家。这个“时光机”就是SVN（Subversion），它记录着项目代码每一次的改动。迁移的目的可能有很多：老服务器太旧了、想换到性能更好的机器上、或者是公司IT架构调整。

在动手之前，我们必须明确一个核心原则：保证数据完整，历史记录一个都不能丢。这意味着，不仅仅是现在的最新代码，连十年前某个程序员提交的那行“Hello World”注释，都得原封不动地搬到新家。

应用场景分析：

  • 硬件升级：旧服务器生命周期结束，迁移至新物理机或虚拟机。
  • 服务整合：将分散在不同服务器的多个SVN仓库，集中迁移到一台新的服务器上，便于管理。
  • 平台切换：从Windows服务器迁移到更稳定的Linux服务器，或者反之。
  • 容灾备份：建立一套完整的、可随时切换的备用SVN环境。

准备工作清单：

  1. 新服务器：已经安装好操作系统，并确保网络畅通。
  2. 权限：你需要在旧服务器上有读取所有仓库数据的权限，在新服务器上有创建文件和目录的权限。
  3. 停服窗口：通知所有团队成员一个明确的“维护时间”，在此期间禁止提交代码，保证迁移时数据是静止的。
  4. 备份！备份！备份！：在开始任何操作前，务必备份旧服务器上整个SVN的存储目录（通常是/svn或/var/svn）。这是你的救命稻草。

二、 分步详解：手把手把数据“搬”过去

迁移的核心步骤其实就两步：从旧服务器“打包”数据，然后在新服务器上“解包”恢复。我们用一个最经典、最可靠的方法：使用SVN自带的svnadmin工具。

技术栈声明： 本文所有命令行操作示例，均基于 Linux (CentOS/Ubuntu等) + Subversion (svn) 技术栈。这是企业中最常见的SVN服务环境。

步骤1：在旧服务器上“打包”仓库

假设我们的旧SVN仓库放在 /opt/svn/repos 目录下，里面有两个仓库：project_a 和 project_b。

首先，我们需要进入仓库所在的目录，然后使用 svnadmin dump 命令将仓库内容导出为一个独立的文件，这个文件包含了全部的历史记录。

# 切换到旧服务器的仓库目录
cd /opt/svn/repos

# 使用 svnadmin dump 命令导出 project_a 仓库
# 命令格式：svnadmin dump [仓库名] > [导出的文件名]
svnadmin dump project_a > /tmp/project_a.dump

# 同样，导出 project_b 仓库
svnadmin dump project_b > /tmp/project_b.dump

命令注释：

  • svnadmin dump：这是SVN自带的仓库转储工具，它会遍历仓库的所有版本（revision），生成一个可读的文本格式文件。
  • >：这是Linux的重定向符号，意思是将命令输出的内容，不是显示在屏幕上，而是写入到后面的文件里。
  • /tmp/project_a.dump：我们指定将导出的数据存放到 /tmp 目录下，并命名为 project_a.dump。/tmp 目录通常有足够的空间，且是临时存储的理想位置。

导出的 .dump 文件有多大？ 它基本等于你的仓库所有历史版本数据的总和。如果仓库很大，这个过程可能需要一些时间，请耐心等待。

步骤2：将“打包”文件传输到新服务器

文件打包好后，我们需要把它弄到新服务器上。这里推荐使用 scp 命令，它可以通过SSH安全地复制文件。

# 在旧服务器上执行，将打包文件复制到新服务器（假设新服务器IP是 192.168.1.100）
# 命令格式：scp [本地文件] [用户名]@[新服务器IP]:[新服务器上的路径]
scp /tmp/project_a.dump /tmp/project_b.dump root@192.168.1.100:/tmp/

命令注释：

  • scp：Secure Copy的缩写，基于SSH协议的文件传输命令。
  • root@192.168.1.100：指定新服务器的登录用户（root）和IP地址。
  • :/tmp/：冒号后面是新服务器上存放文件的路径。这里我们同样放到 /tmp 目录。

输入命令后，会提示你输入新服务器 root 用户的密码。传输时间取决于你的网络速度和文件大小。

步骤3：在新服务器上准备新家并“解包”

现在，登录到你的新服务器（192.168.1.100）。

首先，我们需要安装SVN服务软件，并创建一个目录来存放未来的仓库。

# 1. 安装 Subversion（以CentOS为例）
yum install -y subversion

# 2. 创建SVN仓库的总目录，例如 /data/svn_repos
mkdir -p /data/svn_repos

# 3. 使用 svnadmin create 命令创建一个空的仓库结构
# 注意：这里只是创建容器，数据还没放进去
svnadmin create /data/svn_repos/project_a
svnadmin create /data/svn_repos/project_b

接下来，就是最关键的“解包”恢复步骤，使用 svnadmin load 命令。

# 切换到新服务器的临时文件目录
cd /tmp

# 将 dump 文件的数据，加载（恢复）到新创建的仓库中
# 命令格式：svnadmin load [新仓库路径] < [dump文件名]
svnadmin load /data/svn_repos/project_a < project_a.dump
svnadmin load /data/svn_repos/project_b < project_b.dump

命令注释：

  • svnadmin load：与 dump 对应，它将 .dump 文件中的数据按版本顺序“回放”到指定的空仓库中，重建所有历史。
  • <：这是输入重定向符号，意思是把后面文件的内容，作为前面命令的输入。这里就是把 project_a.dump 文件的内容“喂给” svnadmin load 命令。

这个过程也会花费一些时间，屏幕上会滚动显示正在加载的版本号。看到“Committed revision XXXX.”这样的最终提示，就表示加载成功了。

四、 迁移后的收尾与验证工作

数据搬过去了，但工作还没完。新家需要通水通电（配置访问），并且我们要检查一下家具（数据）是否都完好无损。

1. 配置新服务器的SVN访问

通常我们使用 svnserve 作为服务或者配置Apache+SVN模块。这里以简单的 svnserve 为例：

# 编辑仓库的配置文件，设置访问权限（以project_a为例）
vi /data/svn_repos/project_a/conf/svnserve.conf

# 找到并修改以下几行，去掉行首的 # 号
anon-access = none      # 匿名用户无权限
auth-access = write     # 认证用户可读写
password-db = passwd    # 指定用户名密码文件

# 编辑密码文件，添加用户
vi /data/svn_repos/project_a/conf/passwd
# 在 [users] 部分添加，例如：
# harry = harryssecret
# sally = sallyssecret

# 启动 svnserve 服务，监听默认的3690端口
svnserve -d -r /data/svn_repos
# -d 表示以守护进程（后台）方式运行
# -r 指定仓库的根目录，客户端访问时只需写相对路径，如 svn://服务器IP/project_a

2. 至关重要的数据验证

这是确保迁移成功的最后一道关卡。

  • 基础检查：使用 svnlook 命令查看新仓库的最新版本号，与旧仓库对比。

    svnlook youngest /data/svn_repos/project_a

    这个数字应该和旧仓库 project_a 的最后一个版本号完全一致。

  • 完整性检查：svnadmin verify 命令可以校验仓库内部数据是否完整、无损坏。

    svnadmin verify /data/svn_repos/project_a

    如果没有任何错误输出，仅显示“Verified revision XXXX”，则说明仓库数据完好。

  • 真实操作验证：

    1. 找一个测试用的客户端电脑。
    2. 使用 svn checkout svn://新服务器IP/project_a 签出代码。
    3. 查看日志 svn log，确认历史提交记录都在。
    4. 尝试做一次小的修改并提交 (svn commit)，看是否成功。
    5. 更新 (svn update) 看是否正常。

    只有客户端能完整地读、写、看到所有历史，迁移才算真正成功。

五、 技术优缺点、注意事项与总结

技术优缺点：

  • 优点：
    • 绝对可靠：svnadmin dump/load 是SVN官方工具，能100%保证版本历史的完整性。
    • 过程清晰：每一步都有明确的输入和输出文件，便于监控和排错。
    • 通用性强：无论在哪种操作系统（Linux/Windows）之间迁移，.dump 文件都是通用的。
    • 附带压缩：可以在dump时使用 --deltas 参数或在传输前后用 gzip 压缩，节省空间和带宽。
  • 缺点：
    • 停机时间：为了保证数据一致性，必须在dump时锁定仓库或停止服务，对于超大仓库，停机时间可能较长。
    • 手动操作多：相比一些全自动化工具，步骤略显繁琐，需要一定的运维知识。

关键注意事项：

  1. 时机选择：务必在团队非活跃期（如深夜、周末）进行，并提前广而告之。
  2. 备份先行：再次强调，操作前备份旧数据是铁律。
  3. 权限迁移：svnadmin dump/load 不包含 authz（精细权限）和 passwd（用户密码）配置。你需要手动将旧服务器 conf/ 目录下的这些配置文件复制到新仓库对应位置，并仔细核对。
  4. 钩子脚本：如果旧仓库设置了 hooks（如提交前检查代码格式的 pre-commit），这些脚本也需要手动复制到新仓库的 hooks/ 目录，并确保脚本在新服务器的环境下能正常运行（注意脚本语言解释器路径、依赖工具等）。
  5. 客户端切换：迁移完成后，需要通知所有开发人员，将客户端工作副本的服务器地址指向新的IP或域名。他们可以简单地使用 svn switch --relocate 命令来切换，而无需重新检出整个项目。

文章总结： SVN服务器迁移就像一次精密的数字搬家，核心在于“完整”与“有序”。通过 svnadmin dump 完整备份历史，通过 svnadmin load 在新环境有序重建，再辅以细致的配置迁移和严格的验证流程，就能实现平滑、安全、无损的迁移。整个过程虽然步骤明确，但考验的是执行者的细心和耐心。记住，充分的预案、清晰的沟通（对团队成员）和严谨的验证（对数据本身），是任何一次成功迁移的三大基石。当你看到团队成员在新服务器上顺利提交代码的那一刻，这次迁移行动就圆满成功了。