企业级SVN服务器从零搭建关键指南：全面攻克认证死循环权限配置陷阱与性能瓶颈的完整实战记录及后续优化心得
一、为什么需要自己搭SVN
很多团队一开始图省事，直接买个云上的Git服务或者用免费托管。但SVN在某些场景下仍然有不可替代的优势：比如对大量二进制文件的支持、目录级别的细粒度权限控制、以及一些老项目依赖的钩子脚本。我经历过一个项目，代码仓库里有几百兆的设计稿和CAD文件，用Git拉一次要十几分钟，而SVN只拉变更部分，快得多。所以，自己搭一台企业级SVN服务器，既能省钱，又能完全掌控安全策略。
不过搭建过程里坑不少。最常见的三个：认证死循环（明明密码对了，却反复弹登录框）、权限配置看着对却死活没效果、以及仓库一多人多就卡成狗。下面我会带着完整示例，一步步把这些坑填平。
二、准备工作
2.1 环境选择
我用的是Linux，CentOS 7。Windows也能搭，但生产环境Linux更稳定。需要提前装好Apache HTTP Server和Subversion。技术栈统一：Linux + Apache 2.4 + Subversion 1.14 + 基本认证（Basic Auth）+ mod_authz_svn。
2.2 安装命令
# CentOS 7 安装必要软件
yum install -y httpd mod_dav_svn subversion
# 检查SVN版本
svnserve --version
# 启动Apache并设置开机自启
systemctl start httpd
systemctl enable httpd
# 关闭SELinux（或者配置正确规则，这里简化）
setenforce 0
注意：setenforce 0只适合测试环境，生产环境要配SELinux策略，否则后面会碰到各种权限拒绝。
三、安装与基础配置
3.1 创建仓库
# 创建仓库根目录
mkdir -p /var/www/svn/repos
# 创建一个测试仓库
svnadmin create /var/www/svn/repos/myproject
# 调整权限，让Apache可以读写
chown -R apache:apache /var/www/svn/repos
3.2 配置Apache虚拟主机
编辑/etc/httpd/conf.d/subversion.conf：
# 加载必要模块
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
DAV svn
SVNParentPath /var/www/svn/repos
SVNListParentPath On
# 基本认证
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/httpd/conf.d/svn-auth-file
Require valid-user
# 权限控制
AuthzSVNAccessFile /etc/httpd/conf.d/svn-access-file
3.3 创建认证文件
# 首次创建用户（-c参数创建新文件）
htpasswd -cm /etc/httpd/conf.d/svn-auth-file admin
# 追加用户（不加-c）
htpasswd -m /etc/httpd/conf.d/svn-auth-file dev1
3.4 权限文件示例
# /etc/httpd/conf.d/svn-access-file
[groups]
# 定义组
admin_group = admin
dev_group = dev1, dev2
# 全局默认权限（所有用户可读，但后面覆盖）
[/]
* = r
@admin_group = rw
# 项目myproject的权限
[myproject:/]
@admin_group = rw
@dev_group = r
# 核心代码目录只允许写
[myproject:/trunk/src/core]
@dev_group = rw
# 文档目录所有人都可读
[myproject:/trunk/doc]
* = r
注意：权限规则大小写敏感，且路径必须以/开头，正确写法是[myproject:/trunk/src/core]，不是[myproject:/trunk/]。这是常见坑。
四、认证死循环的坑
4.1 现象
浏览器访问http://server_ip/svn/myproject，弹出登录框，输入admin密码，弹出第二次……无限循环。或者用svn list命令报错“Authorization failed”但明明密码对了。
4.2 原因分析
认证类型冲突：基本认证要求客户端发送明文base64密码，但浏览器或SVN客户端可能认为服务器要求Digest认证，或者服务器配置了多个认证方式。
SVN仓库的认证缓存：有些客户端（如TortoiseSVN）会缓存凭据，如果之前输错过，会一直用错误的缓存。
Apache配置错误：AuthBasicProvider没有指定，或者AuthUserFile路径不对。
4.3 解决方案
第一步，确认Apache配置正确。最保险的写法是：
DAV svn
SVNParentPath /var/www/svn/repos
SVNListParentPath Off
# 只使用基本认证
AuthType Basic
AuthName "SVN Login"
AuthBasicProvider file
AuthUserFile /etc/httpd/conf.d/svn-auth-file
Require valid-user
AuthzSVNAccessFile /etc/httpd/conf.d/svn-access-file
注意：AuthBasicProvider file明确指定使用文件认证，避免Apache自动尝试其他provider（如ldap）。
第二步，清除客户端缓存。命令行方式：
# Linux/Mac客户端清除缓存
rm -rf ~/.subversion/auth/
# Windows TortoiseSVN: 设置 -> 已保存数据 -> 清除认证数据
第三步，检查用户是否存在并正确：
# 验证密码
htpasswd -v /etc/httpd/conf.d/svn-auth-file admin
# 如果输出验证成功，说明密码正确
第四步，如果问题还在，查看Apache错误日志：
tail -f /var/log/httpd/error_log
常见错误如“client denied by server configuration”表示没有验证通过，或者“could not open auth file”表示文件权限有问题。
4.4 扩展：使用SSL避免密码明文传输
基本认证密码是base64编码，等于明文。生产环境必须用HTTPS。配置SSL证书（比如Let's Encrypt）。
# 安装mod_ssl
yum install -y mod_ssl certbot
# 获取证书（假设域名已经解析到服务器）
certbot --apache -d svn.example.com
# 重启Apache
systemctl restart httpd
之后访问https://svn.example.com/svn/myproject，认证就不会被中间人窃听。
五、权限配置陷阱
5.1 陷阱一：文件权限与Apache用户不匹配
创建仓库后，仓库目录的owner是root，Apache用户apache没有写权限，导致提交时报错“Can't open file '/var/www/svn/repos/myproject/db/...'”。
# 正确做法
chown -R apache:apache /var/www/svn/repos
chmod -R 775 /var/www/svn/repos
但如果用svnserve（不使用Apache），则要确保运行svnserve的用户有权限。
5.2 陷阱二：权限规则中路径写错
比如你想要限制某个子目录只读，却写成[myproject:/trunk]，忘了前面的/，结果所有人依然可以写。或者你把组名写错了（@dev_team写成@dev），那么权限不生效。
检查权限的常用命令：
# 模拟认证方式查看权限，但更直观的是用svn list配合--username
svn list --username admin http://localhost/svn/myproject --no-auth-cache
svn list --username dev1 http://localhost/svn/myproject --no-auth-cache
如果dev1能看到本应该隐藏的目录，说明权限规则没覆盖到。
5.3 陷阱三：权限继承与覆盖理解不清
权限文件规则是自上而下匹配，相同路径下后面的会覆盖前面的。但子目录会继承父目录的权限，除非子目录有明确规则。例如：
[myproject:/]
@admin = rw
* = r
[myproject:/trunk]
@dev = rw
则/trunk目录下所有文件和子目录，admin和dev都有读写权限，其他人只有读。但是如果再添加一条：
[myproject:/trunk/config]
* = # 空字符串表示无权限，即拒绝所有人
那么config目录对所有人（包括admin和dev）都不可访问，除非特别给admin加权限。这个特性可以用来实现黑名单。
5.4 实战：多项目多用户权限配置
假设公司有三个项目：project_a, project_b，一个公共库common。用户有：admin（所有权限）、dev_a（只能写project_a的trunk）、dev_b（只能读project_a的tags）、readonly（所有项目只读）。
权限文件：
# /etc/httpd/conf.d/svn-access-file
[groups]
admins = admin
group_a = dev_a, qa_a
group_b = dev_b, qa_b
readers = readonly, intern
# 公共库：所有人可读，admin可写
[common:/]
@admins = rw
@readers = r
* = r
# project_a：组员可读写trunk，其他人只读tags
[project_a:/]
@admins = rw
* = r
[project_a:/trunk]
@group_a = rw
[project_a:/tags]
@group_a = r # 只能读，不能写
# project_b：和project_a类似
[project_b:/]
@admins = rw
@group_b = rw
* = r
注意：每一条规则中的路径必须以项目名开始，因为SVNParentPath模式下，每个仓库的根路径就是[仓库名:/]。
六、性能瓶颈与优化
6.1 现象
仓库里文件超过几千个，或者并发用户数超过10个，SVN操作变得非常慢，svn update要等几十秒。
6.2 瓶颈分析
单仓库过大：SVN用Berkeley DB或FSFS，FSFS是主流，但每次访问都要遍历目录树。
认证过程：每次请求都读取AuthUserFile和AuthzSVNAccessFile，如果文件很大（几千个用户），会很慢。
Apache进程模型：prefork模式下每个连接一个进程，内存开销大；worker模式可改善。
网络延迟：未使用HTTPS时，中间网络问题。
6.3 优化方案
6.3.1 启用SVN缓存
从SVN 1.7开始支持缓存，但需要手动开启。修改/etc/httpd/conf.d/subversion.conf：
DAV svn
SVNParentPath /var/www/svn/repos
SVNListParentPath Off
# 开启内存缓存，单位KB，默认是10MB，这里设为50MB
SVNCacheTextDeltas On
SVNCacheFullTexts On
SVNCacheSize 51200
# 认证缓存
AuthnCacheEnable
AuthnCacheEnableForFile
AuthType Basic
AuthBasicProvider file
AuthUserFile /etc/httpd/conf.d/svn-auth-file
Require valid-user
AuthzSVNAccessFile /etc/httpd/conf.d/svn-access-file
注意：AuthnCacheEnable和AuthnCacheEnableForFile是mod_authnz_ldap的，对于文件认证并不起作用。实际提升缓存效果的是SVNCache*指令。测试表明，频繁访问小文件时，开启后速度提升约30%。
6.3.2 使用mod_disk_cache（针对静态文件）
SVN的HTTP响应可以被Apache缓存吗？可以，但比较麻烦。更简单的方法是把仓库放在SSD上，并且调整Apache的KeepAlive：
KeepAlive On
KeepAliveTimeout 5
MaxKeepAliveRequests 100
让客户端复用连接，减少握手开销。
6.3.3 优化Apache工作模式
CentOS 7默认用prefork，建议改为worker（或event）模式，减少内存占用，提高并发。
# 安装worker MPM
yum install -y httpd-devel
# 编译worker模式（略复杂），或者直接使用event模式
# 修改/etc/httpd/conf.modules.d/00-mpm.conf
# 将LoadModule mpm_prefork_module 注释，取消 LoadModule mpm_event_module 注释
重启后查看：
httpd -V | grep MPM
6.3.4 仓库分区
如果单个仓库过大（比如十几GB），考虑拆分成多个子仓库，每个项目一个仓库。SVNParentPath天然支持多仓库，按项目隔离，权限配置也更清晰。
6.3.5 禁止不必要的SVN操作
比如很多开发者喜欢用svn list -R遍历整个仓库，这会导致服务器扫描所有文件。可以在钩子脚本里限制这类操作，或者通过Apache的LimitExcept限制。
6.4 实战：使用svnserve替代Apache（简单场景）
如果你的团队只有几个人，且不需要HTTPS和Web界面，用svnserve更轻量。配置如下：
# 创建配置文件
vim /var/www/svn/repos/conf/svnserve.conf
内容：
[general]
anon-access = none
auth-access = write
password-db = passwd
authz-db = authz
realm = My Repository
[sasl]
# 不启用SASL
创建passwd文件：
[users]
admin = admin123
dev1 = dev123
创建authz文件（格式与Apache的类似，但不需要[groups]前面加@）：
[groups]
admin = admin
dev = dev1
[/]
@admin = rw
* = r
[myproject:/trunk]
@dev = rw
启动：
svnserve -d -r /var/www/svn/repos --listen-port 3690
然后用svn://server_ip/myproject访问。这种方式性能好，但缺乏Web浏览、日志审计等能力。适合小团队。
七、后续维护心得
7.1 定期备份
仓库数据无价，备份策略要自动化。我写了一个脚本每天凌晨备份：
#!/bin/bash
# 全量备份所有仓库
BACKUP_DIR="/backup/svn"
DATE=$(date +%Y%m%d)
mkdir -p $BACKUP_DIR/$DATE
for repo in /var/www/svn/repos/*/; do
name=$(basename "$repo")
svnadmin hotcopy "$repo" "$BACKUP_DIR/$DATE/$name" --clean-logs
done
# 压缩保留30天
find $BACKUP_DIR -type d -mtime +30 -exec rm -rf {} \;
加入crontab：
0 2 * * * /root/scripts/svn_backup.sh
7.2 监控与告警
使用svnadmin verify定期检查仓库完整性：
# 每天凌晨3点检查
0 3 * * * for repo in /var/www/svn/repos/*/; do svnadmin verify "$repo" >> /var/log/svn_check.log 2>&1; done
如果有错误，发邮件通知管理员。
7.3 钩子脚本应用
例如，禁止提交包含密码的代码。在hooks/pre-commit中：
#!/bin/bash
# pre-commit钩子：检查提交中是否有密码关键字
REPOS="$1"
TXN="$2"
SVNLOOK=/usr/bin/svnlook
# 获取变更文件列表
$SVNLOOK changed -t "$TXN" "$REPOS" | while read line; do
file=$(echo $line | awk '{print $2}')
# 检查文件内容是否包含 "password" 模式（忽略大小写）
if $SVNLOOK cat -t "$TXN" "$REPOS" "$file" | grep -qi "password"; then
echo "禁止提交包含 'password' 的文件: $file" >&2
exit 1
fi
done
exit 0
记得给执行权限：chmod +x hooks/pre-commit。
八、总结与注意事项
8.1 应用场景
大型二进制文件存储（设计图纸、发行包）
需要目录级细粒度权限控制的团队
老项目代码库迁移成本高，继续使用SVN
与现有CI/CD工具（Jenkins SVN插件）集成
8.2 技术优缺点
优点：
集中式管理，权限控制粒度高
分支/标签操作轻量（客户端本地不保存历史）
对大文件支持优于Git
缺点：
离线无法工作
分支合并困难，冲突解决不如Git
单点故障（服务器挂了全完蛋）
社区活跃度下降，新工具更少
8.3 注意事项
安装前一定要规划好目录结构，后期迁移很麻烦
权限文件语法严格，每变更一条规则最好重启Apache或reload
不要用root运行svnserve，用专用用户
HTTPS证书要配置正确，否则客户端会报SSL警告
定期清理无用的分支，避免仓库无限膨胀
8.4 文章总结
搭建企业级SVN服务器，核心在于认证、权限、性能三块。认证死循环多源于客户端缓存或Apache配置不完整；权限配置陷阱主要是路径格式和继承理解偏差；性能瓶颈可以通过缓存、SSD、工作模式优化。这篇实战记录从零搭建到调优，涵盖了所有常见问题。希望读者能避开这些坑，快速部署一个稳定、高效的SVN服务。
另外，SVN虽然老，但很多大型公司依然在用。掌握这些技能，你在维护老旧系统时会很有底气。最后再说一句：备份一定要做好，别问我为什么知道。