1. 搭建前必须想清楚的事：方案选型与场景匹配
聊到Linux下的版本控制，很多人第一反应是Git。但如果你去一些传统行业、外包协作或公司内网环境里转一圈，会发现SVN服务的进程还坚挺地跑着，有些甚至一跑就是七八年没重启过。这不奇怪——SVN部署简单、权限模型直观、稳定性极高，对很多没有复杂Code Review流程的团队来说，它比Git更省心。这篇文章是我实际部署SVN服务的一份完整记录，从选型、安装、建库、配置权限，到systemd托管、备份恢复、钩子脚本，以及我踩过的几个坑，全部讲透。适合运维工程师、后端开发，还有那些只是想在内网快速搭一套靠谱版本控制系统的朋友。照着做，半小时就能跑起来。
1.1 场景决定工具：集中式与分布式的真实边界
SVN和Git的争论我见过太多次，每次都吵不出结果。原因很简单，两套工具的底层理念完全不同：SVN是集中式，所有历史版本都保存在服务端，客户端拿到的只是某个时间点的快照；Git是分布式，每个克隆出来的仓库都是完整历史，离开服务器照样能提交、回滚、查记录。
这带来一个现实差异：SVN天然适合“服务端权威”的场景，比如外包协作、项目验收、需要一个统一口径去发布和回溯的交付流程。Git则更适合开源社区、多分支并行的产品型研发团队，尤其是那种每个成员都希望本地拥有完整历史的场景。
我自己的选型经验很直接：如果团队规模在十人以内，主要需求就是“文件能共享、改动能回滚、权限能隔离”，SVN完全够用。如果团队已经习惯了细粒度分支协作，比如功能分支满天飞、每天反复rebase，那就别折磨自己，直接上Git。工具合理性永远要看场景，而不是看谁更潮。盲目把老项目强行从SVN迁到Git，成本不低，收益却未必明显，这种事我劝你慎重。
1.2 为什么服务端要选Linux
SVN服务端在Linux上的优势，我用四个字概括：省心、耐操。
省心体现在依赖少。Subversion服务端本质就一个svnserve进程加一个文件系统存储，装完就能跑，不需要数据库，不需要中间件，也不需要额外运行时。耐操体现在稳定性和资源占用上，svnserve跑起来内存占用经常只有几十MB，一台512MB内存的虚拟机带几十个仓库完全没压力。我甚至见过一台跑了好几年的老机器，上面同时跑着svnserve和几个内部Web服务，系统负载常年稳定。
另外Linux环境的管理工具链非常成熟，systemd托管、cron定时备份、SSH远程维护，这些都已经是一套标准化操作。相比之下，Windows上固然有图形化运维界面，但要么收费授权，要么权限模型和命令行体系不够灵活。对于大多数公司来说，Linux + SVN的组合是最有性价比的选择。
1.3 访问协议选型：svn://、svn+ssh://、http(s)://
搭建之前还要明确一个关键点：客户端用什么协议访问仓库。这直接决定了后续配置的复杂度。
| 访问协议 | 认证方式 | 传输加密 | 优点 | 适用场景 |
|---|---|---|---|---|
| svn:// | 自带passwd/user认证 | 明文 | 搭建最简单，权限独立 | 内网开发环境，团队规模不大 |
| svn+ssh:// | 复用系统SSH账号 | 加密 | 不用单独维护SVN密码，与SSH体系打通 | 已有堡垒机和SSH密钥管理的团队 |
| http(s):// | HTTP Basic或LDAP认证 | 可通过TLS加密 | 支持浏览器直接看目录，便于对接统一认证 | 跨网络协作，需要Web浏览的团队 |
我大多数场景默认选svn://，快、直接，权限用authz文件控制，所有认证信息都在SVN自己的体系里，和系统账户完全隔离。如果一定要在公网或跨机房使用，那上http(s)更合适，配一层Apache加TLS，浏览器也能访问，还能对接公司现成的LDAP。svn+ssh虽然传输加密，但和系统账号耦合太深，给别人开个SVN账号就得给他开系统账号，对项目组来说管理负担反而更大。
2. 部署前的准备：核心概念与环境梳理
很多人搭建SVN失败，不是因为命令不会敲，而是没理解仓库、工作副本、版本号这些基础概念之间的关系。先花五分钟把这些骨架搭起来，后面的操作就是顺水推舟的事。
2.1 先把这几个概念记住，后面的操作才好懂
- 仓库（Repository）：服务端存储版本数据的目录集合，通过
svnadmin create生成，里面包含了配置、钩子、数据库等完整结构。 - 工作副本（Working Copy）：客户端通过
svn checkout从仓库拉取下来的本地目录，日常改动的场所。 - 版本号（Revision）：每次提交后全局递增的整数，SVN里整个仓库共用一个版本号序列，这和Git每个分支各自编号完全不同。
- 权限三件套：
svnserve.conf是主配置，passwd存用户名和密码，authz存路径级权限规则。 - 钩子脚本（Hooks）：仓库事件触发时自动执行的脚本，比如提交后同步Web目录、发通知。
这些概念不用背，但你得在脑子里有个画面：客户端连上svn://协议，打进用户名密码，系统先去查passwd确认身份，再去查authz确认这个身份对目标路径有什么权限，通过之后才开始读写操作。
2.2 确认系统环境与安装基础包
先看当前机器上有没有已经装过Subversion：
svnserve --version如果提示命令不存在，就按系统类型安装。Debian系（Ubuntu、Debian、Deepin等）用apt：
sudo apt update sudo apt install -y subversion红帽系（CentOS、RockyLinux、AlmaLinux等）用yum或dnf：
sudo yum install -y subversion装完再次执行版本检查：
svnserve --version | head -5能看到版本号和“Copyright (C) ... The Apache Software Foundation”这类输出，就说明服务端、客户端命令行工具已经全部就位。需要注意，Subversion的客户端和服务端是同一个包，不需要单独安装客户端工具。如果你还有独立的开发机需要连仓库，在开发机上同样装subversion即可。
2.3 磁盘与目录规划
仓库文件存放位置建议单独规划，不要直接丢在根目录或临时目录。我习惯把所有仓库统一放在/data/svn下，理由很简单：方便备份、方便扩容、方便权限隔离。
sudo mkdir -p /data/svn如果你的机器上有独立数据盘，建议把这块分区挂载到/data/svn，例如运维同事给了一块/dev/vdb1，可以这样挂载：
sudo mount /dev/vdb1 /data/svn如果希望开机自动挂载，还要把这行写入/etc/fstab。不挂载也不是不能用，但数据盘和系统盘分离，能在系统损坏时多一道保障。容量上，SVN的历史数据增长比很多人想象的快，尤其是仓库里存放了图片、压缩包这类二进制资源，所以/data/svn至少预留20GB比较稳妥。
2.4 三种安装方式对比
除了apt/yum直接安装，还有源码编译和Docker两种选择。我把这三条路的优缺点列个表：
| 安装方式 | 优点 | 缺点 | 我的建议 |
|---|---|---|---|
| 包管理器安装 | 依赖自动解决，更新方便 | 版本可能比上游略旧 | 首选，覆盖绝大多数场景 |
| 源码编译 | 版本新，可定制编译参数 | 依赖多，编译耗时长，维护成本高 | 除非官方源版本实在老到无法接受，否则不推荐 |
| Docker容器 | 环境隔离，迁移方便 | 多一层容器维护和资源开销 | 适合测试环境，生产环境不太建议 |
我生产环境基本不用Docker跑SVN服务端。SVN服务本身就是个极简单进程，直接装进系统里，用systemd管理，出问题排查路径最短。容器虽然能提供一致性，但对SVN这种依赖极少的服务来说，有点杀鸡用牛刀。当然如果你的公司强推容器化，Docker跑SVN也不是不能用，只是备份和端口映射要多留几个心眼。
3. 完整搭建实操：从安装到第一个提交
下面进入正题，我把整个搭建过程按执行顺序拆开。假设系统是全新的，仓库规划在/data/svn。
3.1 安装服务端
Debian系列：
sudo apt update sudo apt install -y subversionCentOS / Rocky系列：
sudo yum install -y subversion装完顺手验证：
svnserve --version | head -3只要能看到类似svnserve, version 1.14.2的输出即可。到这一步，命令行下的svn、svnadmin、svnlook、svnserve四个核心工具都已在PATH里。
3.2 创建仓库并看懂目录结构
创建仓库前的根目录和第一个测试仓库：
sudo mkdir -p /data/svn sudo svnadmin create /data/svn/demo sudo ls -l /data/svn/demo你会看到仓库目录里有这些组成部分：
conf/：配置文件目录，稍后重点操作的对象db/：版本数据存储目录，底层用的是FSFS格式hooks/：钩子脚本模板locks/：仓库锁目录format：仓库格式版本说明文件README.txt：默认说明文件
这里有个很容易犯的错：新手看到db目录以为可以手改，于是直接往里塞文件。千万不要这么做，SVN的版本数据必须通过svn命令操作，绕过工具直接改db只会把仓库搞坏。
3.3 配置认证与路径权限
打开/data/svn/demo/conf/svnserve.conf，把内容调整成下面这样：
[general] anon-access = none auth-access = write password-db = passwd authz-db = authz realm = demo逐项说明：
anon-access = none：禁止匿名访问。如果不设这一项，默认是read，等于任何人不需要密码就能把代码拉走，这个坑必须堵上。auth-access = write：认证用户拥有读写权限。password-db = passwd：指向同目录下的passwd文件。authz-db = authz：指向同目录下的authz文件。realm = demo：认证域名称，客户端会在本地记住它，防止多个仓库认证信息串掉。
接下来编辑passwd文件：
[users] alice = password_alice_321 bob = bob_secure_2024这里有个安全细节必须做：passwd文件是明文存储密码的，权限一定要收紧：
sudo chmod 600 /data/svn/demo/conf/passwd最后编辑authz文件，给用户分配路径权限：
[groups] dev_team = alice, bob [/] * = r @dev_team = rw含义很直白：dev_team组包含alice和bob，仓库根路径/下所有登录用户可读，dev_team成员可读写。如果你希望仓库对无权限用户彻底关闭，那要改成：
[/] * = @dev_team = rw* =表示“所有人都无任何权限”，这样就只有显式授权的人才能访问，更严格。
3.4 启动svnserve并验证端口
核心启动命令：
sudo svnserve -d -r /data/svn解释一下参数：
-d：以守护进程方式运行，后台启动。-r /data/svn：设置仓库根目录为/data/svn。
-r参数非常关键，它决定了客户端URL的写法。设了-r /data/svn，客户端访问svn://服务器IP/demo就是/data/svn/demo这个仓库。如果不加-r，客户端就必须写成svn://服务器IP/data/svn/demo，路径又长又容易打错。
启动后立刻验证端口：
sudo ss -lntp | grep 3690看到LISTEN 0.0.0.0:3690就说明服务正常监听了。SVN默认端口就是3690/tcp，客户端和服务端之间的协议走这个端口。
3.5 注册为systemd服务实现开机自启
直接用svnserve -d启动的进程，重启机器就没了，而且进程意外退出后也不会自动拉起。生产环境必须交给systemd托管。
创建/etc/systemd/system/svnserve.service：
[Unit] Description=Subversion Server After=network.target [Service] Type=simple ExecStart=/usr/bin/svnserve --foreground -r /data/svn Restart=on-failure RestartSec=3 PrivateTmp=true [Install] WantedBy=multi-user.target这里有个值得说的细节：Type=simple配合--foreground参数，让svnserve以前台方式运行，systemd能直接感知主进程状态。有些人习惯用Type=forking搭配-d后台参数，那样需要额外指定PIDFile，反而多一层麻烦。
应用配置并启动：
sudo systemctl daemon-reload sudo systemctl enable --now svnserve sudo systemctl status svnserve看到active (running)就说明服务已被systemd接管，以后开机自动启动，异常退出也会自动拉起。
提示：如果
svnserve --version显示的命令路径不是/usr/bin/svnserve，用which svnserve查一下实际路径，替换上面ExecStart里的路径。
3.6 客户端全流程验证
现在从客户端的角度完整走一遍。假设你用的是另一台装有subversion的机器，或者直接在本机模拟客户端。
检出仓库：
svn checkout svn://127.0.0.1/demo demo --username alice首次连接会提示输入密码，认证通过后会生成一个demo目录。
进入目录，创建文件并提交：
cd demo echo "# demo project" > README.md svn add README.md svn commit -m "init repository"看到类似下面的输出就成功了：
Adding README.md Transmitting file data . Committed revision 1.再测试一次更新：
svn update工作副本已经是最新的，所以不会产生新内容。到这一步，一套最小可用的SVN服务就搭建完成了。
4. 日常运维不可缺的环节：权限、备份与钩子
服务跑起来只是开始，真正体现运维水平的是权限控制、数据备份和自动化钩子。这一节全是实战细节。
4.1 细粒度目录授权与权限生效机制
实际项目中很少只有“全员可读写”这一种需求。举个例子：alice是项目负责人，需要全库读写；bob只是文档维护者，只能写/docs目录。
authz这样配：
[groups] admin = alice doc_writer = bob [/] * = @admin = rw [/docs] @doc_writer = rw * =解释一下这里的权限规则：
/下* =，表示除了admin组成员，其他用户没有仓库根路径的访问权。/docs下@doc_writer = rw，bob在docs目录获得读写权。/docs下* =，非doc_writer组成员没有docs路径权限。
authz是按“最具体路径优先”来匹配的，所以bob虽然整库无权限，但他能访问docs目录。这种模型非常适合按模块划分职责的团队。
passwd和authz修改之后不需要重启svnserve，新的认证请求会自动读取最新内容。不过如果客户端之前已经连过，可能需要让用户重新执行一次认证，或者清一下本地的认证缓存，否则会一直使用旧信息。
4.2 定期备份：hotcopy与dump双管齐下
备份是SVN运维不能跳过的一环。我推荐的组合是“hotcopy每日备份 + dump每周逻辑备份”。
hotcopy是物理级备份，直接把整个仓库复制一份，恢复最快：
sudo svnadmin hotcopy /data/svn/demo /backups/svn/demo-$(date +%F)dump是逻辑备份，把版本数据导出成文件流，适合长期归档和跨版本迁移：
sudo svnadmin dump /data/svn/demo | gzip > /backups/svn/demo-$(date +%F).dump.gz恢复dump时先建一个空仓库，再把数据load进去：
sudo svnadmin create /data/svn/demo-new sudo gunzip -c /backups/svn/demo-xxxx.dump.gz | svnadmin load /data/svn/demo-new为什么两种备份都要做？hotcopy恢复时快，但它对仓库格式版本敏感；dump是文本流格式，兼容性强。生产环境通常hotcopy每天凌晨跑，dump每周跑，然后都同步到另一台机器或者对象存储。
cron示例，每天凌晨2点执行hotcopy：
0 2 * * * svnadmin hotcopy /data/svn/demo /backups/svn/demo-daily4.3 钩子脚本：提交后自动同步Web目录
很多小团队没有完整CI/CD流水线，最朴素的需求是“代码提交后，Web目录自动更新”。这正是post-commit钩子的典型场景。
进入hooks目录，基于模板创建脚本：
cd /data/svn/demo/hooks cp post-commit.tmpl post-commit sudo chmod +x post-commit编辑post-commit，加入同步逻辑：
#!/bin/sh REPOS="$1" REV="$2" export LANG=zh_CN.UTF-8 WEB_DIR=/var/www/demo /usr/bin/svn update "$WEB_DIR" --username alice --password 'alice_pass' --non-interactive >> /var/log/svn-post-commit.log 2>&1这里我要提醒三个坑：
WEB_DIR必须已经是一个从该仓库checkout出来的工作副本，否则svn update会报“is not a working copy”。- 脚本必须有可执行权限，否则钩子静默不执行，连日志都不会有。
- 建议用单独的svn账号做自动同步，不要用root账号，也不要和日常开发账号混用。
4.4 用svnlook做提交审计
每次提交后把改动记录追加到审计日志，这个习惯能帮你少背很多锅。继续在post-commit里追加：
/usr/bin/svnlook changed "$REPOS" -r "$REV" >> /var/log/svn-changes.log /usr/bin/svnlook log "$REPOS" -r "$REV" >> /var/log/svn-changes.logsvnlook是只读分析工具，不会修改仓库数据。这样不管谁在哪个版本号提交了什么文件、说明写了什么，都会留痕。出了事故查一下这个日志，责任一目了然。
4.5 常用运维命令速查表
| 需求 | 命令 |
|---|---|
| 查看仓库最新版本号 | svnlook youngest /data/svn/demo |
| 查看某个版本的提交说明 | svnlook log -r N /data/svn/demo |
| 查看某个版本改动哪些文件 | svnlook changed -r N /data/svn/demo |
| 停止服务 | sudo systemctl stop svnserve |
| 重启服务 | sudo systemctl restart svnserve |
| 压缩仓库存储 | sudo svnadmin pack /data/svn/demo |
5. 安全加固与常见问题排查实录
服务能跑通只是及格，把网络安全和异常处理做到位才是高分。最后一节集中讲安全策略、资源隐患以及我踩过的真实坑。
5.1 防火墙与网络层加固
svnserve默认走3690端口，而且用的明文协议，所以一定不能把这个端口直接暴露到公网。防火墙层面要精确限制来源IP。
Debian系的ufw配置：
sudo ufw allow from 192.168.1.0/24 to any port 3690 proto tcp红帽系的firewalld配置：
sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.1.0/24 port protocol=tcp port=3690 accept' sudo firewall-cmd --reload准确限制来源网段比单纯放行端口安全得多。如果公司有跳板机或内部堡垒机，只放行跳板机IP就行，开发人员全部通过跳板访问，这能把风险面压缩到最小。
5.2 监听地址与端口变更
如果服务器有多个网卡，只想让SVN监听内网地址而不是所有地址，可以在启动参数上用--listen-host指定：
/usr/bin/svnserve --foreground -r /data/svn --listen-host 192.168.1.10 --listen-port 3691假设你想更换默认端口，改--listen-port即可。注意改了之后systemd配置里的ExecStart也要同步改，客户端访问URL也得跟着变。不要只改命令行不改systemd，否则重启后又会回到旧配置。
5.3 服务端资源与存储性能
SVN日常用下来CPU和内存压力都很小，真正的隐患往往在磁盘。文件数量特别多、提交频繁的仓库，垃圾数据会越积越多，用svnadmin pack可以整理FSFS格式的数据，缩小存储占用并提升读性能：
sudo svnadmin pack /data/svn/demo另外，磁盘空间和inode是两种不同的告警维度，都要盯：
df -h /data df -i /datadf -h看的是容量，df -i看的是文件节点数量。inode满了会报“No space left on device”，但df -h可能还显示有大把空间，这个坑很隐蔽。
5.4 常见问题速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| svn: E170013: Unable to connect to a repository | 服务未启动，或防火墙拦截了3690端口 | 确认systemctl status svnserve，用ss -lntp查监听状态，放行防火墙端口 |
| 提交时报authorization failed | passwd与authz配置不一致，或用户无对应路径权限 | 检查passwd里用户是否存在，检查authz对应路径权限 |
| URL access forbidden for unknown | svnserve.conf的anon-access没有设为none | 将anon-access = none写入svnserve.conf |
| Can't open file ... Permission denied | 仓库目录属主和svnserve运行用户不一致 | chown -R调整属主，或让svnserve以仓库属主身份运行 |
| post-commit钩子不执行 | 脚本没可执行权限，或脚本内命令路径不对 | chmod +x post-commit，手工执行脚本看报错输出 |
| 客户端提示E170004: expected version | 仓库格式版本与客户端兼容性有问题 | 升级客户端的subversion版本到和服务端相近 |
| svnserve启动后立刻退出 | 端口被占用或仓库路径配置错误 | journalctl -u svnserve看日志，前台运行svnserve查具体报错 |
5.5 一个真实踩坑记录
有一回公司内网突然所有客户端都无法checkout代码，看起来svnserve进程正常、3690端口也在监听，但就是连接失败。当时排查了很久，最后才发现仓库所在分区是inode耗尽了。磁盘容量还有富余，但海量小文件把inode表塞得满满当当，清理掉临时文件后服务立刻恢复。从那以后我养成了每周至少看一次df -h和df -i的习惯，这种资源层面的问题不盯紧，早晚给你来一次突发事故。
5.6 如果需要Web浏览：加一层Apache桥梁
如果团队希望不用客户端工具、直接用浏览器查看仓库目录，可以给svnserve再加一层Apache支持，用mod_dav_svn实现。
安装依赖：
sudo apt install -y apache2 libapache2-mod-svn在Apache配置中加入仓库映射，例如启用dav_svn配置：
<Location /svn> DAV svn SVNPath /data/svn/demo AuthType Basic AuthName "SVN Server" AuthUserFile /etc/apache2/svn-auth.htpasswd Require valid-user </Location>创建Web访问账号：
sudo htpasswd -c /etc/apache2/svn-auth.htpasswd alice重启Apache：
sudo systemctl restart apache2此时浏览器访问http://服务器IP/svn就能看到仓库里的目录结构了。如果配合TLS证书，就能升级成https://访问。Apache和svnserve可以共用同一个仓库，两者不冲突。唯一的差别是Apache走的是HTTP认证体系，如果想继续使用authz的路径级权限，还要额外加载mod_authz_svn模块，把AuthzSVNAccessFile指向刚才那个authz文件。
5.7 别把SVN当文件服务器
最后说一句经验之谈：SVN适合管源码、文档、脚本这类文本型资源，不适合管大量二进制文件。如果你把几百MB的安装包、编译产物往仓库里堆，仓库体积会迅速膨胀，checkout和update变得奇慢无比，版本库也越来越难备份。遇到这种情况，正确的做法是在SVN里只保留源码和配置文件，二进制产物放到专门的制品管理平台，然后用钩子脚本把它们发布出去。
我在实际项目中体会最深的一点是：SVN的稳定和简单，让它非常适合承担“公司内部版本管理基础设施”这个角色。配置一次，后面很少需要折腾，剩下的精力可以放到备份策略、权限梳理和提交规范这些真正重要的事情上。如果你还在纠结“该用Git还是SVN”，我建议先想清楚自己的协作场景，别让技术潮流替你做决定。希望这份完整的搭建记录能帮你少踩几个坑，快速跑起来一套可靠的内网SVN服务。
