SVN想换服务器怎么办？，迁移数据时要注意什么？

SVN想换一台服务器，稳妥做法不是让开发各自重新checkout，而是先在旧库完成一次全量备份，再导入新服务器，最后让所有工作副本执行svn switch –relocate切到新地址。

svn服务器迁移到新服务器：动手前先盘清家底

换服务器之前最容易忽略的,是仓库数量、权限文件、钩子脚本和外部引用，这些内容不会自己跑到新机器上，行业共识认为，迁移前不做完整盘点，是造成上线后权限丢失、提交报错的主要原因。

加载中

Simmc服务器入坑新手教程

MC龙king

3453551

原视频地址

• 确认旧服务器上有几个SVN仓库,路径是否统一
• 确认仓库规模,选择合适的备份方式：hotcopy或dump
• 确认认证方式：svnserve使用passwd与authz，Apache则还要检查httpd配置
• 确认hooks目录里有哪些钩子脚本,尤其是pre-commit和post-commit
• 确认svn:externals外部引用是否写死了旧服务器域名或IP
• 确认新服务器Subversion版本不低于旧版本,避免仓库格式不兼容

如果团队使用TortoiseSVN、命令行客户端混合环境，迁移前还要统一通知客户端版本，多数情况下，Subversion 1.8及以上版本使用svn relocate，更老版本才需要加--relocate参数。

svn换服务器怎么迁移？四步操作流程可直接照做

svn服务器迁移步骤：备份、传输、恢复、切换

整个迁移可以拆成四步,每一步都有对应命令可以验证结果。

第一步：在旧服务器上备份仓库

推荐使用svnadmin hotcopy，它比直接复制目录更安全，能保证备份时仓库不处于写入状态。

• 单仓库备份命令：

  svnadmin hotcopy /data/svn/project /backup/project_backup

• 多仓库批量备份：

  for repo in /data/svn/; do
  svnadmin hotcopy "$repo" "/backup/$(basename "$repo")_backup"
  done

如果仓库特别大或需要减少停机时间,也可以使用svnadmin dump做增量备份，但恢复速度通常比hotcopy慢。

第二步：把备份传输到新服务器

备份文件或目录需要完整跨机传输,建议使用rsync，它可以断点续传，也能校验文件一致性。

• 传输hotcopy目录：

  rsync -avz /backup/ user@new-server:/backup/

• 如果网络不稳定,加--partial参数：

  rsync -avz --partial /backup/ user@new-server:/backup/

第三步：在新服务器上恢复仓库

如果用的是hotcopy备份,恢复最简单，直接把目录放到目标路径即可。

• 确认仓库路径：

  mkdir -p /data/svn
  cp -a /backup/project_backup /data/svn/project

• 如果用的是dump文件,需要先创建仓库再加载：

  svnadmin create /data/svn/project
  svnadmin load /data/svn/project < /backup/project.dump

• 恢复后校验仓库UUID：

  svnlook uuid /data/svn/project

旧库和新库的UUID必须一致,否则客户端工作副本会认为这不是同一个仓库，导致relocate失败。

第四步：切换所有客户端工作副本

这是开发团队最关心的一步,命令行用户进入项目工作副本根目录，执行：

• 新版Subversion：

  svn relocate https://new-server/svn/project

• 旧版Subversion：

  svn switch --relocate https://old-server/svn/project https://new-server/svn/project

TortoiseSVN用户操作路径：右键工作副本目录，选择TortoiseSVN，点击Relocate，输入新仓库地址，确认即可，不需要重新checkout。

svn服务器更换IP地址后客户端如何快速切换

如果只是换了IP地址,仓库内容没变，说明迁移动作更轻，客户端核心操作仍然是relocate，但有几个场景需要区别处理。

• 只换IP,协议和路径不变：直接relocate到新IP地址
• IP变域名：把旧IP替换为新域名后relocate
• 从svn://换成http://或https://：relocate同样有效，但要确认新服务器已经配置好对应服务
• 从IP换成带端口的地址：必须把端口号写进新地址，例如svn://新IP:3690/svn/project

如果团队数量不大,可以在内部群统一发一条新仓库地址，让开发自行右键relocate，团队人数较多时，建议管理员写一个批处理或shell脚本，从项目根目录统一执行relocate。

svn迁移到git对比：这次换服务器要不要顺便换版本控制

换服务器是一个时间窗口,部分团队会纠结要不要顺便从SVN迁到Git，这个决策不能只凭“Git更流行”就下结论，要看实际协作方式。

如果当前团队没有分布式协作需求,只是因为换服务器就迁移到Git，很容易把权限体系和分支流程的改造成本摊到开发日常中，反过来，如果团队本来就计划转向Git，换服务器时同步做迁移，确实可以省去一次单独停机安排。

批量脚本：让svn服务器迁移步骤自动跑完

仓库数量超过十个时,手工操作容易漏，管理员可以先写好备份、传输和校验脚本，减少人为失误。

• 旧服务器备份脚本示意：

  #!/bin/bash
  BACKUP_DIR=/backup/svn_$(date +%F)
  mkdir -p "$BACKUP_DIR"
  for repo in /data/svn/; do
  svnadmin hotcopy "$repo" "$BACKUP_DIR/$(basename "$repo")"
  done

• 新服务器恢复脚本示意：

  #!/bin/bash
  for repo in /backup/svn_/; do
  name=$(basename "$repo")
  if [ ! -d "/data/svn/$name" ]; then
    cp -a "$repo" "/data/svn/$name"
  fi
  done

• 迁移完成后批量校验UUID：

  for repo in /data/svn/; do
  echo "$repo: $(svnlook uuid "$repo")"
  done

这些命令保存为shell脚本,放在新服务器执行，比手动一个个创建仓库更可靠。

迁移后最容易忽略的三个坑

钩子脚本没有被一起迁移

hooks目录不会自动跟随仓库同步,旧服务器的/data/svn/project/hooks/pre-commit需要单独复制到新仓库对应位置，并保持可执行权限。

• 检查路径：/data/svn/project/hooks/
• 复制命令：

  scp -r old-server:/data/svn/project/hooks/pre-commit /data/svn/project/hooks/
  chmod +x /data/svn/project/hooks/pre-commit

authz权限文件路径指向旧目录

很多团队把authz文件放在仓库外部,比如/data/svn/conf/authz，迁移后svnserve.conf里的authz-db如果还写旧路径，权限会直接失效。

• 检查/data/svn/project/conf/svnserve.conf
• 确认authz-db行指向新服务器实际文件路径
• 如果从Windows迁到Linux,注意路径分隔符和大小写

svn:externals外部引用写死旧地址

有些项目会通过svn:externals属性引用公共库，换服务器后，这些外部引用仍然指向旧地址，更新时就会失败。

• 查看外部引用：

  svn propget svn:externals /data/svn/project

• 需要手动把旧地址批量替换为新地址,如果外部引用很多，可以用脚本遍历所有目录并执行svn propset svn:externals "新值" 路径。

迁移后必须做的验证

新服务器上线前,建议先做一轮只读验证，再开放提交。

• 在测试机执行svn checkout，确认可以完整拉取仓库
• 让开发在旧工作副本上执行svn update，确认连接新地址成功
• 提交一个测试改动,再删除该改动，验证pre-commit和post-commit钩子是否跑通
• 查看svn log -l 5，确认历史记录完整
• 检查Apache或svnserve日志,确认没有认证报错

业内专家指出,迁移工作是否成功，关键不在于命令能不能跑通，而在于权限和钩子这类隐性配置有没有跟着走，一次迁移如果只验证了更新和提交，很可能漏掉权限异常。

svn换服务器相关问题解答

svn换服务器后工作副本还能用吗？

能用,只要新旧仓库UUID一致，在工作副本根目录执行svn switch --relocate 旧地址 新地址，或者新版客户端执行svn relocate 新地址即可，TortoiseSVN用户右键选择Relocate操作，不需要重新checkout，如果UUID不一致，才会出现工作副本无法识别的情况。

svn服务器迁移到新服务器必须停机吗？

不需要全流程长时间停机,可以先做一次全量hotcopy备份，再在正式切换前做一次短时间只读，同步差异数据，多数团队会选择下班后或周末操作，客户端只需完成relocate就能继续工作。

svn服务器迁移步骤中UUID不一致怎么办？

如果使用svnadmin load恢复，UUID会原样保留，如果手工创建仓库并把目录拷过去，UUID可能不同，此时工作副本会提示“Repository UUID mismatch”，解决办法是让所有用户重新relocate，或者直接重新checkout，已经提交到旧仓库的历史记录不会因为UUID不同而丢失，但工作副本与新仓库的关联会断裂。