SVN资源库的服务器地址不是创建时手动填写的，而是由你启动SVN服务时指定的监听IP和端口决定，格式通常为svn://服务器IP:端口号/仓库名称，或者http://域名/svn/仓库名称。
很多人第一次用TortoiseSVN创建资源库，会困惑“服务器地址在哪看”，这个地址确实不是SVN自己生成的一个固定网址，而是你部署服务端后，需要主动拼出来的连接字符串，搞清楚它的构成规则，比单纯记一个IP要实用得多，因为后期换服务器、改端口、配域名都用得上。
SVN服务器地址的真实构成：一个URL拆开看
行业共识认为，SVN服务器地址本质上就是一个统一资源定位符，无论你用的是VisualSVN Server、CollabNet Subversion Edge，还是直接在Linux上敲命令部署原生SVN,最终给客户端填写的都是这样一个URL。
协议头决定访问方式
SVN支持好几种访问协议，每种协议对应的端口和适用场景完全不同,常见的有以下三类：
- svn://协议：这是SVN自带的自定义协议，走的是svnserve服务，默认端口3690，它配置简单，内网开发效率高，但不支持加密传输,适合局域网或公司内部使用。
- http://或https://协议：通过Apache HTTP Server或VisualSVN Server（Windows平台）来提供服务，默认端口80/443，也可能被自定义成8080等，它支持Web浏览、SSL加密、权限分级管理,适合跨公网协作或与公司统一认证做集成。
- file://协议：仅本地单机使用，地址直接指向磁盘路径，比如file:///D:/Repositories，这种方式不需要任何服务，别人也访问不了,只适合个人测试或者做备份仓库。
主机部分可以写IP也可以写域名
主机部分就是你的服务器入口，在局域网的场景下，一般直接写服务器的内网IP，例如192.168.1.100，如果服务器绑定了域名，那这里就可以使用svn.example.com,甚至不需要带端口号。
有一种比较常见的误区是：有些人以为创建资源库时的路径就是服务器地址，其实D:\Repositories\myproject只是服务器上的磁盘目录，客户端需要用svn://192.168.1.100/myproject这样的URL才能连进来,目录路径和访问URL是两个维度的概念。
仓库路径要区分根仓库和子仓库
如果你在svnserve的配置里把根目录指向D:\Repositories，那么D:\Repositories\myproject这个仓库在客户端看到的路径就是/myproject，如果你的根指向了D:\Repositories\myproject本身，那客户端直接用svn://192.168.1.100/就能访问。
创建SVN资源库后，如何准确查看自己的服务器地址
很多教程会教你怎么创建仓库，但在“创建SVN资源库的服务器地址是什么”这一步往往一笔带过,我直接给你一套在Windows和Linux上都能用的确认思路。
第一种情况：用TortoiseSVN创建本地仓库
- 右键新建文件夹，选择“创建仓库”,直接建立一个本地库。
- 此时如果你右键仓库文件夹选择“属性”看“Subversion”标签页，你会看到仓库根目录的URL，它是
file:///D:/Repositories/MyRepo。 - 这个地址只有你自己能用，要让同事连进来,你必须启动svnserve服务。
- 在命令行执行
svnserve -d -r D:\Repositories，然后告诉同事填入svn://你的IP/MyRepo。
第二种情况：用VisualSVN Server管理仓库
VisualSVN Server这类图形化服务端比较省事，在它的控制台里，每个仓库旁边都会直接列出仓库URL，通常长这样：https://servername.domain.com/svn/MyRepo/，如果服务器端口是8443,URL里就会自动带上端口号。
判断服务器地址时，核心看两点：一是服务端配置的协议头，二是仓库在根目录下的相对路径,把这两样拼起来就得到了完整地址。
第三种情况：Linux下原生SVN服务
Linux上配置SVN较为常用，假设你在/data/svn下建立了仓库：
- 先修改
/data/svn/conf/svnserve.conf，将anon-access和auth-access配置好。 - 然后运行
svnserve -d -r /data/svn，这里的-r参数决定了访问根。 - 客户端访问地址就是
svn://服务器IP/仓库名。 - 验证地址是否打通，可以在服务器上执行
svn info svn://localhost/仓库名,能看到仓库版本号就说明服务正常。
SVN服务器地址格式与端口在真实项目里怎么选
地址的写法不是固定的，得结合你的网络环境和团队规模来定，我遇到过不少团队，内网开发用svn://跑得飞起，但一旦要跨地域合并代码,就出现连接超时或权限难管控的问题。
内网小团队：svn://3690是最高效的组合
- 连接速度快
- 配置部署成本极低
- 不需要额外安装Web服务，服务器资源占用小
- 一条核心指令轻松维护：
svnserve -d -r /repository/root
公网或跨团队协作：https://是最稳妥的选择
- 通过Apache绑定SSL证书，所有代码传输都加密,避免被中间人截获源码。
- 支持LDAP、AD域认证,可以按目录做精细权限控制。
- 开发者用浏览器直接浏览代码,在非SVN客户端的设备上也可以快速查阅。
- 比较适合对合规性要求高的金融或政企项目。
SVN服务器地址能固定成域名吗
当然可以，比如你公司在公网有固定域名svn.example.com，只要在DNS解析里把它指向SVN服务器的公网IP，同时路由器上做好端口映射到内网机器，客户端用域名访问完全没问题，这种情况下地址就是http://svn.example.com/svn/MyRepo/,不需要带着IP写。
svn://本地IP无法访问？大概率是这四处没配对
有时候在服务器本地用svn://localhost/仓库名能访问，但同事在局域网内用svn://192.168.x.x/仓库名就是连不上，这个问题在“创建SVN资源库的服务器地址是什么”这个疑问背后其实相当普遍,排查思路按照下面顺序来。
检查svnserve是否真的在运行
- 在Linux上用
ps -ef | grep svnserve确认进程存在。 - 在Windows上用
netstat -ano | findstr 3690确认端口处于监听状态。 - 如果进程没起来，检查是否用了
-d后台模式启动,常见的坑是关掉终端之后服务就随之中断了。
检查防火墙有没有放行端口
Linux下的iptables或firewalld默认往往不会放行3690端口,需要手动添加规则：
firewall-cmd --permanent --add-port=3690/tcp- 然后
firewall-cmd --reload生效 - Windows服务器需要在“高级安全Windows防火墙”里针对3690端口新建一条入站允许规则
检查svnserve.conf是否解开了注释
一个相当典型的坑是：svnserve.conf里默认的# password-db = passwd和# authz-db = authz这两行还带着注释，即使服务启动了，也会因为无法读取密码文件而拒绝连接,客户端只会报一个通用错误。
你需要用记事本或vim打开conf目录下的svnserve.conf，把这几个配置项前面的注释符去掉，并确保路径有效,留存后重启svnserve即生效。
检查仓库目录的权限
以Linux环境为例，svnserve进程通常是以独立用户身份运行的，如果你存放仓库的目录所有者是root，SVN进程本身读写受限，也会导致客户端连接失败或在checkout时报权限错误,最简单的处理办法是让仓库所属用户和SVN进程保持一致。
记不住IP时，用hosts文件给SVN服务器地址起个别名
这是个实操效率技巧，如果你被问“SVN服务器地址多少，我发你微信，你复制粘贴一下”，那大概率是因为大家脑子里都没存那个IP，与其每次去问运维,不如自己做一个本地映射。
- 在Windows系统中打开
C:\Windows\System32\drivers\etc\hosts - 追加一行：
168.1.100 svnserver - 保存后，在TortoiseSVN的URL栏里直接写
svn://svnserver/MyRepo就能访问
这样做还有个额外好处：当服务器IP发生变化时，你只需要改hosts文件里的映射，不需要去修改一堆工作副本的重新定位地址，不过要注意，hosts文件只对单台电脑生效，团队协作中如果大家都这么做,就得约定统一维护。
SVN服务器地址与代码目录结构如何配合设计
如果只是建一个空仓库拉代码，那地址写对就万事大吉，但正规项目里通常一个地址会对应多个路径，客户端访问时需要在URL上补充子目录，比较常见的标准布局是在仓库根下面建trunk、branch、tags三个目录。
- trunk目录：用于存放主线的开发代码,多数提交操作都指向这里。
- branch目录：应用于功能分支或版本分支,适合多人并行开发互不干扰。
- tags目录：用于存放版本快照，发布后打tag,方便后续回溯。
在给同事下发地址时，最好直接给到子目录的完整URL，例如svn://192.168.1.100/ProjectA/trunk，很多新手搞不清楚为什么点开地址后看不到代码，就是因为只给了仓库根地址，而根目录下是空的,代码都散落在trunk里。
迁移服务器时SVN服务器地址怎么平滑切换
换服务器的场景不陌生，老服务器地址要废弃，新资源库服务器地址变了，不改地址不行，但直接改又怕开发同事本地的工作副本断连,恰当的迁移方式能让地址切换带来的影响降到最低。
如果你用的还是同一个仓库目录数据，可以将老仓库用svnadmin dump导出，再在新服务器上执行svnadmin load导入，完成后在新服务器的svnserve配置里指定好仓库根目录，同时在客户端右键选择“重新定位”来替换URL的前缀部分，注意，“重新定位”和“切换”是不同的操作前者只改仓库连接地址，后者是切换整个项目的分支路径,不要搞混。
一个稳健的小建议：迁移当天通知团队尽量不要提交代码，待所有成员都完成了重新定位操作后再恢复常态提交,避免出现版本不一致的冲突。
遇到SVN服务器地址失效时优先检查DNS和端口映射
在实际运维中，不少情况下SVN服务器地址失效并不是SVN本身故障，而是网络层面的问题，如果你用的是域名而非IP，优先用ping svn.example.com和telnet svn.example.com 3690做两步探测，如果ping得通但telnet不通，大概率是服务端没监听或者防火墙挡了，如果ping不通，那就是域名解析或路由的问题,需要按你的云服务商或内网路由策略来处理。
Q&A：创建SVN资源库后常见连接疑问
为什么在TortoiseSVN中填svn://192.168.1.10/repo提示无法连接主机
优先检查客户端是否能ping通该IP，随后在服务器本地确认端口3690是否处于监听状态，如果是云服务器，还需要在安全组中放行TCP 3690端口，不能仅依赖系统防火墙的配置,多数情况下这类错误通常和防火墙策略或svnserve进程未启动直接相关。
创建SVN资源库时可以选择http协议而不是svn协议吗
完全可以，但前提是服务端必须提供对应的HTTP服务模块，例如使用VisualSVN Server时创建的仓库默认就是http或https地址，你可以通过Apache配置反向代理或直接使用svnserve搭配svn://协议，两种协议的仓库在功能上本质一致，主要差异在于端口、加密方式以及Web访问能力。
svn://的默认端口3690可以改成其他数值吗
可以，在启动svnserve时用--listen-port参数指定新端口即可，例如执行svnserve -d -r /data/svn --listen-port 8443，客户端需要填写的地址就变成svn://服务器IP:8443/仓库名，但如果你使用的是VisualSVN Server、Apache这类Web服务的话，端口调整的位置则在该软件的HTTP设置选项里，修改以后需要同步刷新Windows防火墙入站规则,并重启对应服务。