对于“SVN服务器改了IP地址怎么处理”这个问题，答案其实分两头：服务端要确认监听地址和端口配置，客户端则用 svn relocate 一条命令把工作副本的URL指过去，不用重新检出代码,下面把这两头拆开讲清楚。
先弄清楚：SVN的IP到底”藏”在哪个配置里
很多人第一反应是去 svnserve.conf 里翻IP，结果翻半天找不到，原因很简单，SVN本身不存”服务器IP”这个字段,它藏在不同访问方式的配置文件或启动参数里。
三种访问方式，改的位置完全不同
- svn:// 协议（svnserve进程）：IP由启动参数
--listen-host决定，通常写在/etc/sysconfig/svnserve的OPTIONS里。 - http:// 或 https:// 协议（Apache mod_dav_svn）：IP由 httpd 的
Listen指令或VirtualHost决定,跟SVN版本库本身无关。 - file:// 本地访问：压根不涉及网络IP,常见于单机测试或备份恢复场景。
行业共识认为，生产环境里绝大多数故障都不是”SVN配错了IP”，而是服务器换了网卡地址、迁移了机器，配置没跟着走,所以第一步永远是搞清楚你用的是哪种访问方式。
一个高频误判：版本库地址和服务器地址是两回事
svn://192.168.1.10/project 这个URL里，前半段是服务器入口，后半段是版本库路径，服务器换IP，改的只是前半段；版本库搬家，后半段才会变，这两件事要改的配置项不一样，混在一起改,十有八九要出问题。
服务端：svn 服务器换了ip地址怎么切换配置
服务端的改动量其实很小，核心就三件事：监听地址、防火墙、服务重启。
Linux下svn修改服务器地址后要重启服务吗
要重启，改完配置不重启，进程还挂在旧地址上，客户端连过来就是超时,具体路径分发行版略有差异。
以 CentOS / RHEL 系的 svnserve 为例：
- 编辑
/etc/sysconfig/svnserve，把OPTIONS改成：OPTIONS="--listen-host=0.0.0.0 -r /var/svn"
- 更推荐直接监听
0.0.0，这样以后服务器换网卡、加内网IP都不用再动配置。 - 执行
systemctl restart svnserve。 - 验证监听状态：
ss -tlnp | grep 3690或netstat -tlnp | grep 3690,看端口绑的是不是新地址。 - 放行防火墙端口：
firewall-cmd --permanent --add-port=3690/tcp，firewall-cmd --reload。
如果是 Apache 走 HTTP 方式，就改 httpd 配置：
- 检查
/etc/httpd/conf/httpd.conf里的Listen，写成Listen 0.0.0.0:80。 - 如有
VirtualHost，确认ServerName是否还写着旧域名或旧IP。 systemctl restart httpd，再curl -I http://新IP/svn/看返回码。
在服务器上直接验证，不靠猜
重启完后,先在服务器本机跑一次：
svn info svn://新IP/project svn list svn://新IP/project
本机通、外网不通，基本就是防火墙或云安全组的问题，跟SVN配置无关,这个排查顺序能省掉大量来回折腾的时间。
临时救急的老办法
如果是云主机换弹性IP、或者内网切换，来不及改配置，可以在网关层做端口转发或NAT映射，把新地址的3690转发到旧地址，这只适合过渡期，长期这么干会留下隐患后面接手的人根本看不出来这条链路是怎么绕的。
客户端：svn服务器ip地址改变后客户端怎么重新定位
这是搜索量最大的一类问题，结论很明确：用 relocate，不要重新 checkout，重新检出不仅慢,还会丢掉本地未提交的改动。
relocate 到底改了什么
它只改工作副本里记录的版本库根URL，文件和版本历史一个字都不动，因为是同一台服务器换了地址、版本库还是原来那个，所以UUID没变,relocate能顺利通过校验。
命令行操作路径
先看当前URL：
svn info --show-item url
然后在工作副本根目录执行：
svn relocate svn://旧IP/project svn://新IP/project
较新版本也支持只写新地址,让SVN自动推断旧地址：
svn relocate svn://新IP/project
执行完再跑一次 svn info，确认 URL: 那一行已经变成新地址，svn update 试一下能不能正常拉取。
TortoiseSVN 图形界面的走法
小乌龟用户更简单：在工作副本文件夹上右键 → TortoiseSVN → 重定位（Relocate） → 把输入框里的旧IP改成新IP → 确定，整个过程几秒钟,日志窗口会提示重定位完成。
IDEA、Eclipse 这类IDE，先按上面的方法把工作副本重定位好，再进设置里检查版本库地址是否同步更新,否则提交时会继续往旧地址发请求。
什么时候 relocate 会失败
失败基本集中在两种场景：
- 版本库UUID对不上：说明你连的已经不是原来那个库了，可能是新建的库或迁移过来的副本，relocate 会直接拒绝执行，这时候要用
svn switch --relocate或者干脆重新检出。 - 工作副本有冲突或切换状态：先
svn cleanup，把未完成的操作和冲突处理干净,再重定位。
别忘了认证缓存
改完地址后如果一直提示输入密码、或者报认证失败，去清一下本地缓存，Windows 下在 %APPDATA%\Subversion\auth，Linux 下在 ~/.subversion/auth，整个目录删掉重启客户端即可，旧地址的凭据留着,新地址反而可能被顶掉。
长期方案：别让IP成为单点
据统计，中小团队里因为服务器IP变更导致的协作中断，多数都能靠一个习惯避免客户端统一用域名连，不要直接写IP，服务器换地址时，只改DNS解析或内网hosts，客户端一行配置都不用动,relocate也省了。
如果暂时没法上域名，至少做两件事：一是服务端监听 0.0.0 而不是绑死某个网卡地址；二是把 svn relocate 的操作步骤写进团队文档,别等出事了现查。
下面的对比表可以帮助判断该用哪种处理方式：
| 变更场景 | 服务端动作 | 客户端动作 | 是否需重新检出 |
|---|---|---|---|
| 仅服务器IP变化 | 改监听地址并重启 | svn relocate |
否 |
| IP与端口同时变 | 改监听+防火墙 | svn relocate，URL带新端口 |
否 |
| 版本库迁移到新机器 | 部署库并确认UUID一致 | svn relocate |
否 |
| 换成全新版本库 | 无 | svn switch 或重新检出 |
是 |
| 改用域名访问 | 配DNS解析 | 无需操作 | 否 |
业内专家指出，UUID校验是SVN重定位机制里最容易被忽略的一环，它本质上是在替用户确认”你连的还是不是原来那个库”。
svn 改服务器端ip地址 的常见疑问
svn 改服务器端ip地址后，客户端必须全部重定位吗
是，每个本地工作副本都独立记录着版本库URL，服务器端改了地址，所有客户端的工作副本都要各自执行一次svn relocate，服务端无法远程推送这个变更，也没有批量下发的机制，只能靠通知加文档约束，规模较大的团队可以写个脚本遍历本地工作副本目录,逐个执行重定位命令。
svn relocate 和 svn switch 在换IP场景下有什么区别
svn relocate 只改URL前缀，要求新旧地址指向同一个版本库，也就是UUID必须一致，文件内容完全不动。svn switch 是把工作副本切换到另一个分支或另一个版本库，允许UUID不同，会带来实际的文件更新，同一台服务器换IP，用 relocate；换了库或者要切分支，用 switch，选错了轻则报错,重则把本地未提交的改动搞乱。
svn 服务器地址变了但版本库UUID也变了，怎么处理
这种情况说明连接目标已经不是原来的库，relocate 会被拒绝，可行的做法是先确认新库内容与旧库的对应关系，然后用 svn switch --relocate 旧URL 新URL 尝试切换，或者在保留本地改动的前提下重新检出，再把改动覆盖回去，执行前务必先备份整个工作副本目录，SVN的元数据都在隐藏的 .svn 文件夹里,删掉就找不回来了。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/789962.html
