企业官网建设流程全解析

最近接了个小团队的项目，要把几台Windows开发机和一台Linux服务器统一做版本管理。本来想图省事直接上Git，但有个同事是非技术岗，Git那套概念对他来说实在太痛苦。后来我干脆在一台HoRain云服务器上把SVN完整搭了一套，从服务端安装、仓库创建、权限配置再到客户端TortoiseSVN、IDEA、VSCode全流程都捋了一遍，踩了不少坑，也总结了不少经验。这篇就把整个安装过程、配置思路和实操中的坑都写下来，给需要在云服务器上部署SVN的朋友一个完整参考。

SVN虽然"年纪"不小，但在目录级权限控制、锁定机制、非技术同事上手速度这些场景下，依然比Git有优势。尤其是那种"谁改过哪个目录一目了然""按目录给不同人开权限"的传统协作模式，SVN的表达最直接。这篇攻略会覆盖完整流程，适合刚接触SVN的小白，也适合准备从零搭建的运维或开发同学当作操作手册来用。

1. 整体设计与部署思路

1.1 为什么这种场景下仍选择SVN

很多人一听版本管理，第一反应就是Git，但SVN并没有过时。如果你们团队是这种形态：开发、测试、产品、运营混在一起，甚至还有外包人员——每个人的技术基础参差不齐，协作模式又以"按目录认领"为主，SVN往往比Git更划算。我这边选择SVN的核心原因有三点：

第一，目录级的权限控制非常直观。仓库里建好trunk、branches、tags，不同角色对不同目录给只读或读写权限，一条authz规则就搞定了，不需要像Git平台那样建一堆group和project。对于不想把代码权限管得特别细、但又不能全放开的场景，SVN的粗粒度反而刚刚好。

第二，文件锁机制对非技术同事非常友好。SVN的锁是"排他锁"，一个人锁了文件，别人就只能只读，根本不存在"冲突"这回事。做文档、素材、配置文件协作时，这种机制能让完全不懂版本管理的人避免陷入conflict的泥潭。

第三，小团队、小项目用SVN，维护成本几乎为零。服务端一个svnserve进程就完事，不像GitLab那样要吃好几个G内存。HoRain云服务器配置不用太高，1核2G跑SVN绰绰有余，一年下来成本低得可以忽略。

注意：我这里不是说Git不好。Git的本地分支、分布式提交在复杂开发流程里确实强大。但"工具服务于团队"这个原则，比"工具本身是否流行"重要得多。如果团队规模、协作习惯更适合SVN，那就果断用，没必要为了技术时髦硬迁。

1.2 部署方案选型：svnserve还是Apache+mod_dav_svn

SVN在Linux服务端有两种主流部署方式，一种是独立的svnserve服务（默认监听3690端口），另一种是挂在Apache HTTP Server下，走http/https协议。这两种我都用过，说下我的判断。

独立sdsvnserve的方案，最大的优点是配置简单、依赖少。装好subversion包，svnadmin create建仓库，改三个配置文件，启动服务，完事。客户端连接时用svn://IP/仓库名这种地址，清爽直接。缺点是默认的密码认证方式不够安全，密码在passwd文件里是明文存的，走网络也不加密。适合内网或小团队信任环境。

Apache方案则复杂不少，要装httpd、mod_dav_svn、mod_authz_svn，还要折腾SSL证书，但换来的是https加密传输、可以和LDAP/AD集成做统一认证、可以用浏览器直接浏览仓库目录，权限模型也更灵活。适合对安全要求高、需要和公司统一账号体系打通的企业场景。

我最终选的是sdsvnserve。原因很实际：团队人少，服务器上跑的东西也少，没必要为了一个版本管理工具引入Apache这么重的依赖。如果后续真需要走https或者对接LDAP，随时可以迁移，仓库数据是通用的，换个访问通道而已。

1.3 仓库目录结构规划

在创建仓库之前，先把目录结构想清楚，后面能省很多事。SVN社区的标准做法是这样一个三段式结构：

• trunk：主干目录，日常开发的主战场，所有功能最终都要合到这里。
• branches：分支目录，放功能分支、发布分支、个人分支。
• tags：标签目录，存放每个发布版本的快照，打tag后就不允许再改。

我见过不少团队把SVN用成了共享网盘，所有文件一股脑塞在根目录，版本是有了，但管理和回溯一塌糊涂。建议从建库第一天就把这个结构建好，然后在authz里把根目录默认设成只读，只允许trunk和对应分支读写，从机制上逼着大家遵守规范。

2. 核心细节解析与实操要点

2.1 SVN的核心机制，理解这些才能排错

SVN和Git最大的区别在于"集中式"三个字。所有历史记录、版本号都集中在服务器仓库里，本地工作副本只保留一份当前版本的快照。操作流程是：update把服务器最新代码拉到本地，改完commit提交到服务器。版本号是全局递增的，r1、r2、r3……历史是一条直线，没有Git那种分支分叉和DAG的概念。

理解了这个模型，很多坑就很好解释。比如SVN在commit之前必须先update，因为服务器版本比你本地新的时候，SVN会拒绝提交，逼你先合并别人的改动。这个机制看起来死板，但对新手来说反而是保护——它强制要求你每次提交前都同步一次，从源头上减少冲突发生的概率。

仓库的存储格式我建议就用默认的FSFS。以前还有个BDB后端，并发访问不稳定，容易锁库，现在基本被淘汰了。FSFS是纯文件存储，每个版本以文件形式保存在磁盘上，备份恢复都很方便。

2.2 权限模型与配置文件关系

svnserve方案下，权限相关的配置集中在仓库目录下的conf文件夹里，一共三个文件：

• svnserve.conf：服务端主配置，控制匿名访问、认证方式、权限配置文件的路径。
• passwd：存用户名和密码。格式是用户名 = 密码，一行为一个账号。
• authz：存授权规则。负责给不同用户或用户组配置目录级别的读写权限。

这三个文件的关系一定要理清。svnserve.conf是"总开关"，它决定SVN服务器是否要求认证、读取哪份passwd和authz。passwd解决的是"你是谁"的问题，authz解决的是"你能干什么"的问题。很多新手配置半天连不上，要么是总开关没开认证，要么是authz里没给用户任何权限，客户端虽然能连上服务器，但一访问仓库就报Access denied。

注意一点：svnserve.conf里的配置项，前面不能有空格，等号两边倒是可以有空格。这个特性坑过不少人，从网上复制配置时尤其容易带出隐藏空格，导致服务启动正常但权限全部失效。

2.3 权限规则里容易被忽略的几个细节

authz的语法看起来简单，写起来坑不少。最基本的结构是这样：

[groups] dev = alice, bob qa = carol [repo:/] @dev = rw @qa = r * = [repo:/branches/release1.0] @qa = rw

这里有几个细节容易被忽略。第一个细节是* =，这表示"其他所有人都没有权限"，注意等号后面是空的。如果你不写这一行，默认其他用户是有读权限的，这在某些场景下等于权限泄露。我习惯在根目录写上* =，然后逐级放权。

第二个细节是权限的"就近原则"。SVN在判断用户对某个路径的权限时，会从被访问路径开始逐级向上找，找到匹配规则就用，不再向上合并。也就是说，子目录的规则会覆盖父目录的规则，但覆盖的方向是"找到最近一条就停"。比如根目录给了@dev = rw，某个子目录你想单独限制某人只读，就要在该子目录下单独配一条规则。

第三个细节是[repo:/]这种带仓库名的写法。如果你的svnserve用-r参数指定了仓库根目录，客户端访问的是svn://IP/仓库名/trunk，那么authz里的路径必须以仓库名:/开头，而不是直接[/]。这个坑我踩过，差一个仓库名，整条规则就静默失效。

3. 实操过程与核心环节实现

3.1 服务器环境准备与安装Subversion

我用的这台HoRain云服务器是CentOS 7.x系统，2核4G配置，跑SVN完全是杀鸡用牛刀，但考虑到后续可能还要跑其他服务，留点余量没坏处。系统装好后，第一步先把系统包更新到最新：

yum update -y

然后安装SVN服务端。CentOS的源里自带subversion，不用额外加仓库：

yum install -y subversion

安装完成后验证一下版本：

svnserve --version

如果输出类似svnserve, version 1.7.14 (r1542130)这样的信息，说明装好了。Ubuntu/Debian系系统的话，安装命令是apt install -y subversion，其他步骤完全一样。

实操心得：这里不要图省事用yum install -y subversion的旧版本就不管了。SVN早期版本有比较严重的安全漏洞（就是热词里提到的.svn漏洞），新版已经修复。装完后务必确认版本在1.8以上，如果发行版自带版本太老，建议去官网下载新版本源码编译安装，或者找第三方源更新。安全这关不能省。

3.2 创建仓库与初始化目录结构

我的习惯是统一把SVN数据放在/data/svn目录下，这样备份、迁移、权限管理都集中在同一个地方：

mkdir -p /data/svn cd /data/svn svnadmin create myrepo

svnadmin create执行后会生成一个myrepo目录，里面有conf、db、hooks、locks等子目录。db是真正的版本数据存储目录，后面做备份就是要备份整个仓库目录。conf是配置文件目录，hooks是钩子脚本目录，可以放一些提交后自动同步、自动发邮件的脚本。

仓库建好后，第一时间把trunk、branches、tags目录结构创建出来。这里有两种方式，我推荐先本地建目录再一次性导入：

mkdir -p /tmp/svn-init/trunk /tmp/svn-init/branches /tmp/svn-init/tags svn import /tmp/svn-init/ file:///data/svn/myrepo -m "初始化目录结构"

执行完后，仓库里就有这三个基础目录了。如果图省事想直接在服务器上建目录，也可以svn mkdir file:///data/svn/myrepo/trunk -m "创建trunk"，但多个目录还是用import一次性完成更方便。

3.3 修改三个核心配置文件

创建仓库时，conf目录下会自动生成svnserve.conf、passwd、authz三个文件的模板。但默认配置基本不能用，要逐一修改。

先说svnserve.conf，最小可用配置是这样的：

[general] anon-access = none auth-access = write password-db = passwd authz-db = authz realm = myrepo

这里anon-access = none表示不允许匿名访问，auth-access = write表示通过认证的用户有读写权限。password-db和authz-db指定了认证和授权文件。realm是个认证领域名，客户端连接时会显示，多个仓库共存时建议改成不同的名字方便区分。

注意：[general]下面每行配置项前面不要加空格。这一点在SVN官方文档里提了很多次，但因为配置文件是Python风格解析，缩进容易引起误解，实际踩坑的人还是很多。如果你改了配置后客户端行为没变化，优先检查这里。

然后编辑passwd文件，添加用户：

[users] alice = 123456 bob = 654321

密码是明文存储的。如果对安全有要求，建议用系统级的SASL认证来加密密码存储。但小团队场景下，明文密码配合防火墙和强密码策略也能接受。我自己是在HoRain云安全组里把3690端口限制到只允许办公室IP访问，相当于加了一层网络层面的保护。

再编辑authz文件，配置权限。我这里的典型配置是：开发组对trunk有读写权限，测试组对tags只读，组长对全部目录有完全控制权：

[groups] admin = charlie dev = alice, bob qa = carol [myrepo:/] @admin = rw * = [myrepo:/trunk] @dev = rw @qa = r [myrepo:/branches] @dev = rw @qa = r [myrepo:/tags] @admin = rw @dev = r @qa = r

这里注意[myrepo:/]前面的仓库名。因为我后面启动svnserve时会用-r /data/svn指定数据根目录，客户端访问地址是svn://IP/myrepo/trunk，所以authz里必须带myrepo:前缀。如果你把-r指定到仓库一级，比如-r /data/svn/myrepo，那authz里就用[/]，因为客户端看到的根就是仓库本身。这两种风格我建议统一用前者，因为多仓库共存时管理最清晰。

3.4 启动服务与开机自启

配置写好后，试启动一下：

svnserve -d -r /data/svn

-d表示以守护进程方式运行，-r指定仓库根目录。启动后检查一下进程和端口：

ps aux | grep svnserve netstat -tlnp | grep 3690

如果3690端口已经在监听，服务就起来了。但这样启动有个问题：服务器一重启，svnserve就没了，还得手动拉起来。我建议写一个systemd服务，开机自动启动：

vi /etc/systemd/system/svnserve.service

内容如下：

[Unit] Description=Subversion Server After=network.target [Service] Type=forking ExecStart=/usr/bin/svnserve -d -r /data/svn ExecReload=/bin/kill -HUP $MAINPID PIDFile=/run/svnserve.pid Restart=always [Install] WantedBy=multi-user.target

然后执行：

systemctl daemon-reload systemctl enable svnserve.service systemctl start svnserve.service

注意ExecStart里svnserve的路径建议用绝对路径，可以先执行which svnserve确认。Type=forking是因为svnserve -d启动后父进程会退出，子进程继续运行，所以systemd要按forking方式跟踪。

3.5 防火墙、安全组与客户端连通性验证

服务端起来后，客户端能不能连上，取决于两件事：服务器防火墙是否放行3690端口，云平台的安全组是否放行了这个端口。

先看服务器防火墙。CentOS 7默认用的firewalld：

firewall-cmd --permanent --add-port=3690/tcp firewall-cmd --reload

然后去HoRain云控制台，找到这台服务器所在的安全组，添加入方向规则，协议TCP，端口3690，源地址按需填写。我的做法是只允许公司固定IP段访问，这样即使svnserve本身密码强度不够，外部也扫不到这个端口。

放行端口后，在本地电脑上试一下连通性。Windows下可以直接在命令行跑：

telnet 服务器IP 3690

如果能看到一个类似svnserve的欢迎信息，说明TCP通道已经通了。接下来在本地任意目录执行一次checkout验证完整链路：

svn co svn://服务器IP/myrepo/trunk

会提示输入用户名和密码，输入alice账号后，如果能看到trunk目录内容，整套服务端就彻底OK了。

4. 客户端配置与日常使用

4.1 TortoiseSVN（小乌龟）安装与中文语言包

Windows下最主流的SVN客户端就是TortoiseSVN，因为图标是个小乌龟，大家习惯叫小乌龟。下载时一定去官网tortoisesvn.org，不要随便在第三方下载站下，那些站点捆绑的一堆垃圾软件能折腾死你。

安装过程一路Next就行，唯一要注意的是安装完成后建议同时装一个同版本的中文语言包。语言包其实是个独立的exe，装完后在小乌龟的Settings -> Language里选择中文，重启资源管理器就生效了。

实操心得：小乌龟安装时可以选择集成到资源管理器的哪些位置，默认全选就行。但如果你装了360之类的软件，它会拦截小乌龟的右键菜单注册，导致桌面右键看不到SVN选项。碰到这种情况，在资源管理器地址栏敲%APPDATA%\TortoiseSVN看看有没有缓存目录，有的话手动重启explorer.exe就能恢复。

安装完小乌龟后，在桌面任意目录右键 -> SVN Checkout，输入svn://服务器IP/myrepo/trunk，签出到本地目录，就能看到绿勾图标了。本地文件修改后图标变成红叹号，提交后恢复绿勾，这套视觉反馈机制对新人来说非常直观。

4.2 IDEA中配置并使用SVN

IDEA自带SVN支持，但首次使用要配一下。打开IDEA，Setting -> Version Control -> Subversion，把"Use command line client"指向svn.exe的路径。这个svn.exe是小乌龟安装目录里自带的命令行工具，装了TortoiseSVN后一般不需要单独装另一个客户端。

这里有个常见的坑：如果在IDEA里一直提示"Subversion executable not found"，说明IDEA没有找到svn.exe。去小乌龟安装目录（一般是C:\Program Files\TortoiseSVN\bin）确认一下svn.exe是否存在。小乌龟在安装时可以勾选"command line client tools"，如果当时没勾，重装时补上就行。

配置好之后，从IDEA里Checkout代码：VCS -> Checkout from Version Control -> Subversion，输入仓库URL，选好本地目录，就能把项目导进来了。日常使用就三件事：

• Update Project：把服务器最新代码拉下来，等同于命令行svn up。
• Commit：提交本地改动，右键文件或整个项目直接提交。
• Integrate Directory：合并分支，这个对应svn merge，后面细说。

IDEA对SVN的文件状态显示也很直观，文件在编辑后有蓝色或绿色的标记，能和Git插件区分开。团队里有从Git转过来的同学，重点是提醒他们SVN没有本地提交，每次提交都会直接进服务器，所以提交前一定要先update。

4.3 VSCode中使用SVN标记文件状态

VSCode是很多前端同事的主力编辑器，要在VSCode里看到SVN的文件状态，装个插件就行。最常用的是svn这个扩展，装好后左侧资源管理器会自动给修改过的文件打上M、A、D这类标记，和GitLens的体验类似。

不过这个插件有个老问题：它依赖VSCode集成的终端，在文件很多的大仓库里刷新状态偶尔会卡顿。我的经验是如果项目特别大，可以在VSCode设置里把svn.path直接指到小乌龟的svn.exe，减少一层终端调用的开销，状态刷新会流畅不少。

4.4 日常操作流程：update、commit、merge与冲突解决

SVN的日常操作流程，我总结成了四句话：先update再修改，改完commit要写清说明，分支合并前先对比，遇到冲突别慌找三方的。

先说update和commit的顺序问题。很多新手直接从Git的习惯里带过来，改完代码就点commit，结果SVN直接弹窗提示"Please update your working copy"。这是因为SVN要求工作副本必须保持"最新可用"状态，如果你改文件期间别人也改了同一文件并提交，你的本地版本已经过期，必须先update把别人的改动合进来，才能commit。这个设计虽然不是最灵活的，但避免了Git里那种"提交了半天才发现有冲突"的尴尬。

再说merge。SVN的merge命令没有Git那么智能，它本质上是"把两棵目录树的差异应用到当前目录"：

svn merge svn://服务器IP/myrepo/branches/feature-a svn://服务器IP/myrepo/trunk

但平时在IDEA或小乌龟里操作更直观。小乌龟右键 -> TortoiseSVN -> Merge，选好来源和目标的URL，它会先模拟一次merge，把即将发生的变更列表展示给你，确认没问题再真正执行。这里强烈建议每次merge之前先做一次"dry run"（试运行），看看会有哪些文件被修改，避免merge上去一堆意料之外的冲突。

最后说冲突。SVN的冲突发生在update或merge时：你改了文件A的第5行，别人也改了文件A的第5行并提交了，系统没法自动决定谁对。Git的做法是三方合并后在文件里标注冲突区域，SVN也是类似，出现冲突的文件会生成额外的.mine、.r新版本号文件。处理方式是打开冲突文件，手工决定保留哪份改动，然后右键标记为已解决。如果是小乌龟，冲突解决对话框里会并排显示三个版本：我的、别人的、合并后的，逐行选完点保存就行。

5. 常见问题与排查技巧实录

5.1 认证失败与权限不足问题

SVN认证失败是最常见的问题，报错通常是Authentication failed或Access denied。前者说明用户名或密码不对，后者说明账号验证通过但没权限访问目标路径。

排查思路按顺序来。先确认passwd里账号是否存在、密码是否正确，注意passwd文件里的注释行会被忽略，但账号行必须是用户名 = 密码的格式，等号两边可以有空格。再确认svnserve.conf里password-db = passwd这一行没被注释掉，很多模板里默认是注释状态，不打开就永远走的是匿名访问。最后确认authz里给这个用户配了对应路径的权限，有时候用户能连上服务，但访问/trunk时报Access denied，而访问其他目录正常，几乎可以断定是authz缺规则。

如果上面都查了还不行，把服务端的日志打开。svnserve默认日志输出到终端，如果用了-d守护进程模式，日志输出到/var/log/svnserve.log之类的地方。看日志是排查一切认证问题的金钥匙。

5.2 SVN certificate validation failed

这个报错通常出现在用svn+ssh://或https://协议访问仓库时，服务端的SSL证书不被客户端信任。比如用Apache + mod_dav_svn配了自签名证书，客户端第一次连接时会报证书验证失败。

如果这是自己搭的内网服务，最省事的做法是在客户端接受该证书。命令行模式下，SVN会提示是否接受证书，输入p即可永久接受。小乌龟则会在弹窗里让用户选择接受并保存。如果不想每次连接都折腾证书，可以把这个服务器的证书导入到Windows证书管理器里，操作路径是：运行certmgr.msc，在"受信任的根证书颁发机构"里导入服务器的自签名证书。

需要提醒的是，如果是公网服务器，建议还是用正规CA签发的证书，不要图省事直接用自签名。特别是在云环境里，域名和数据安全都值得认真对待。

5.3 客户端无法连接服务器：ping通但连不上3690

这是一个非常典型的"网络症状"：服务器ping得通，但SVN客户端连接一直超时或拒连。排查顺序是：先本地确认svnserve进程在跑、3690端口在监听，再检查服务器防火墙，最后检查云安全组。

防火墙的排查命令：

firewall-cmd --list-ports

如果列表里没有3690/tcp，按前面说的加上。安全组这个环节特别容易漏，因为防火墙关掉后本地测试可能通了，但从外部连的时候还是不行——这就是安全组压根没放行。去HoRain云控制台看一下服务器的安全组规则，确认入口方向有TCP 3690的放行规则。

还有一个容易忽略的点：如果服务器上装了fail2ban或类似的安全工具，它们可能会在检测到多次认证失败后临时封禁客户端IP。我就是在这个坑里耗了大半天，最后在fail2ban的日志里看到自己办公室出口IP被封了。

5.4 .svn漏洞与版本安全

热词里有一条".svn漏洞"，这里说清楚来龙去脉。SVN客户端在检出代码后，会在工作副本的每个目录下生成一个.svn隐藏文件夹，里面存的是这个目录的管理元数据。早期SVN版本（1.6及之前）把一些敏感信息存放在.svn/entries或.svn/wc.db里，如果网站上线时把这些.svn目录一起发布到Web服务器，攻击者可以通过访问/.svn/entries等路径，拿到源码文件列表、版本号、甚至部分未提交的代码内容。这就是所谓的.svn漏洞。

新版的SVN（1.7+）把多级目录的.svn统一合并到工作副本根目录的一个wc.db中，风险大幅降低，但依然不建议把包含.svn目录的文件夹直接发布到Web根目录。如果是从旧项目里接手，部署上线前一定要检查Web目录下有没有残留的.svn目录，有的话顺手删掉，或者直接用rsync排除：

rsync -av --exclude='.svn' ./ /var/www/html/

这属于"部署卫生"层面的问题，但真的见过不少团队因为这个问题泄露过源码，有必要单独拎出来说。

5.5 核验码不一致与本地缓存问题

有同学反馈SVN操作时报"核验码不一致"或用小乌龟提交时提示类似校验错误，这个问题的根源一般是本地工作副本的元数据损坏，或客户端缓存出了幺蛾子。

常规处理流程是三步。第一步，在报错的目录上执行小乌龟的Clean up，它会清理中断操作留下的锁和临时信息。第二步，把svn:ignore之类的属性检查一下，确认不是权限或属性设置异常导致的报错。第三步，如果Clean up无效，最粗暴的办法是把该目录删掉重新Checkout一份。

这个问题的底层原因，大部分情况下是本地工作副本文件被外部程序（比如网盘同步工具、杀毒软件）做了不该做的修改，导致本地元数据和服务器对不上。我遇到的最奇葩的一次，是同事把SVN工作目录放到了"坚果云"同步文件夹里，坚果云一直在后台修改文件时间戳，SVN以为所有文件都被外部改动了。所以这里有个非常重要的实操建议：SVN工作副本目录千万不要放进任何网盘同步目录里，OneDrive、坚果云、百度网盘都不行，这几乎必然导致各种莫名其妙的问题。

最后再分享一点个人经验

这套SVN服务我目前在HoRain云上跑了大半年，整体非常稳定，期间只因为一次服务器迁移重启过，systemd服务拉起后一切恢复正常，仓库数据完好无损。回顾整个搭建过程，最大的感受是：SVN的安装和配置本身并不复杂，真正的复杂度来自"规范"二字。目录结构规范、权限分级规范、提交信息规范、分支合并规范，把这些定好，SVN能帮你省下大把团队协作的精力。

如果后续团队迁移到Git，svn2git这样的工具可以把仓库历史完整迁移过去，版本号、提交时间、作者信息都能保留。但如果团队规模一直不大，SVN这套体系再战几年完全没问题。最后再补一句：记得定期备份/data/svn目录，我用crontab每天凌晨打包一次，加上云平台的快照，双保险，哪天误删了仓库也不慌。