SVN服务器和客户端的连接，本质上是客户端拿着一个包含协议、地址、端口和仓库路径的URL，去访问服务器上已经创建好、服务已经启动、账号拥有相应权限的代码仓库；服务器端建好仓库并放行端口，客户端执行一次checkout，连接就打通了。这件事看起来只是”填个地址点确定”，实际上卡住人的往往不是客户端，而是服务器那头的仓库、服务和权限三样没对齐。
SVN服务器和客户端怎么连接：先把服务端的三个前提摆平
连接失败的人里，有相当一部分根本没把服务端准备好，就在客户端反复折腾，业内专家指出，SVN的连接问题多数能在服务端找到根因，服务器这边要同时满足：仓库存在、服务在跑、账号有权限,缺一样客户端都会报错。
服务器端需要先完成的三件事
- 创建仓库：命令行方式执行
svnadmin create /var/svn/project，VisualSVN Server则是在图形界面里右键Repositories新建,仓库名就是后面URL里的路径部分。 - 启动服务：原生svnserve用
svnserve -d -r /var/svn后台驻留，把/var/svn作为根目录；如果配了systemd单元，用systemctl enable --now svnserve更稳妥。 - 开权限：改仓库conf目录下的三个文件，svnserve.conf里把
anon-access设为none，auth-access设为write，password-db指向passwd，authz-db指向authz；passwd里按[users]格式加账号，authz里按[groups]和路径写读写规则。
改完文件不需要重启服务，但账号权限是下一次认证时生效，防火墙这一步经常被漏掉，CentOS系执行firewall-cmd --permanent --add-port=3690/tcp && firewall-cmd --reload，Windows服务器要在安全组或系统防火墙里放行对应端口，业内公认的做法是只放行必要端口,不要图省事整机放开。
两种连接方式：svn:// 和 http(s)://
SVN支持多种访问协议，实际用得最多的是下面两类，选错了URL格式,客户端一定连不上。
| 对比项 | svn://（svnserve） | http(s)://（Apache/VisualSVN） |
|---|---|---|
| 默认端口 | 3690 | 80、443或自定义 |
| URL示例 | svn://192.168.1.100/project | https://svn.example.com/svn/project |
| 认证方式 | 仓库conf里的账号密码 | HTTP认证或集成AD域账号 |
| 部署复杂度 | 低，一个进程搞定 | 中，需配Apache模块或直接用VisualSVN |
| 适合场景 | 内网小团队、快速搭建 | 跨公网、需要域名和HTTPS加密 |
VisualSVN Server装完后默认给的是https://服务器名/svn/仓库名，很多人习惯性写成svn://开头，结果直接报”无法连接”，看清楚服务端用的是什么协议,客户端URL就照着抄。
TortoiseSVN连接SVN服务器步骤与命令行方式的实操对照
Windows上大多数人用TortoiseSVN，操作路径很直观，在本地要放代码的空文件夹里右键，选SVN Checkout，在”URL of repository”里粘贴服务器地址，比如svn://192.168.1.100/project，Checkout directory选本地目录，点OK后弹窗输入账号密码，勾选保存认证信息，等进度条走完,文件夹图标变成绿色对勾就说明连通了。
命令行用户的动作更少,也更容易排查：
svn list svn://192.168.1.100/project --username zhangsan，只列目录，用来验证连接和权限,不改动本地文件。svn checkout svn://192.168.1.100/project /home/dev/project,完整检出。svn info，在已检出的目录里执行，能回显仓库根URL、版本号、最后修改版本,确认自己连的是哪个库。
两种方式底层走的是同一套协议，命令行的好处是报错信息更完整，排查时优先用svn list做最小验证，这里有个细节：认证信息在Windows上缓存在用户目录的Subversion文件夹里，换账号时如果一直提示旧账号，清掉缓存或者加--no-auth-cache重新输入。
局域网和跨公网场景下，SVN服务器地址怎么配置
内网环境最简单，服务器IP固定，客户端直接填svn://192.168.x.x/project或者https://内网域名/svn/project，前提是客户端和服务器在同一网段、能ping通，建议给服务器配静态IP或做DHCP保留，IP一变,全团队的URL都得跟着改。
跨公网访问就要多考虑几层，常见做法是在路由器或云服务器安全组做端口映射，把公网IP的某个端口转到内网3690或443；有域名的话配一条A记录指向公网IP，客户端用域名而不是IP，将来换服务器只改解析，安全上不建议把3690裸奔在公网，走HTTPS加防火墙白名单更稳妥，近年来越来越多的团队改用云托管的SVN服务,本质上也是免去端口映射和公网IP这些琐事。
svn客户端连接服务器失败怎么办：按报错逐层排查
连接不上别急着换软件，先看报错码，它能直接把范围缩小到网络、认证还是权限。
常见报错与对应原因
| 报错关键词 | 大概率原因 | 处理方向 |
|---|---|---|
| E170013 无法连接到URL | 地址写错、服务没起、端口不通 | 先telnet测端口，再看服务进程 |
| E175002 连接被拒绝 | 防火墙拦截、svnserve未运行 | 放行端口、ps -ef查进程 |
| E170001 认证失败 | 账号密码错、passwd文件没生效 | 核对conf配置，注意等号两边空格 |
| E175013 禁止访问 | authz里没给该路径权限 | 检查authz路径写法和用户组 |
| E215004 认证次数过多 | 缓存的旧密码反复重试 | 清除认证缓存后重输 |
按网络、认证、权限三段排查
先断网络：在客户端机器上telnet 服务器IP 3690，不通就是网络层问题，查防火墙、安全组、路由，跟账号无关。再验认证：用svn list带账号访问，报认证失败就去服务器看passwd里用户名和密码是否正确，注意svnserve.conf里被注释掉的配置等于没写。最后看权限：能认证但列不出目录，多半是authz的路径规则没覆盖到，根路径[/]和子路径的继承关系要理清，表示其他人无权限,写错了会把所有人挡在外面。
行业共识认为，记录每次变更的配置内容和时间，能让这类排查少走一半弯路，改完conf记得确认没有多余空格,svnserve对格式比较敏感。
自建SVN服务器和云SVN服务的成本对比
选哪种连接方式，背后其实是成本账，自建需要一台常开的机器或云主机，加上公网IP、带宽、备份和运维人力；云SVN服务按账号数按月计费，公开报价常见几元到几十元每人每月不等，具体看存储和并发，团队规模小、内网为主，自建更划算；人员分散、没有专职运维，托管服务省心，无论哪种，客户端连接的动作是一样的,差别只在URL和谁来保证服务可用。
回到开头那句话：连接成功与否，取决于服务端仓库、服务、权限三样是否就位，客户端只是最后那一次敲门，URL格式对、端口通、账号有权限,checkout自然一路绿灯。
关于SVN服务器和客户端连接的常见问题
svn服务器和客户端怎么连接，必须用同一个网段吗？
不是必须，同一网段只影响内网直连的便利性，跨网段或跨公网只要路由可达、端口放行就能连，区别在于URL里填内网IP还是公网IP或域名，跨公网时优先用HTTPS,避免账号密码明文传输。
svn客户端连接服务器失败怎么办，如何快速定位是服务器问题还是客户端问题？
换一台机器用同样的URL和账号执行svn list，其他机器能连，问题在客户端，重点查认证缓存、URL拼写和本地网络策略；其他机器也连不上，问题在服务端，按端口、服务进程、账号权限的顺序查,这个对照法比反复重装客户端有效得多。
TortoiseSVN连接SVN服务器时提示认证失败，但账号密码确认没错，是什么原因？
常见于服务端svnserve.conf里的password-db路径写错，或者authz没有给该用户任何路径权限，此时认证环节可能通过但授权环节被拒，表现容易混淆，另一个原因是客户端缓存了旧密码，在设置里清除认证数据后重新输入即可；还有一种是密码中含有特殊字符，部分旧版本客户端解析异常,换成字母数字组合测试能快速排除。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/797287.html
