小团队里只要有人问"设计稿最新版在哪"，版本控制这件事就绕不开了。Git 当然好，但碰上几个不那么写代码的同事、几十个大体积的 PSD 和 Excel、加上需要按目录分配读写权限这种需求，SVN 依然是很多人的第一选择——它把整个仓库当成一棵可以按目录授权的树，谁只能读assets、谁可以写docs，配置文件里两行就定死了。而手头有台装了宝塔面板的 Linux 服务器，自然想着把 SVN 也塞进去统一管理。这事儿能做，但面板里没有现成的 SVN 模块，从装服务、建库、配权限，到配提交后自动更新，中间有几处坑几乎每个人都会踩一遍。下面这份记录就是我把这套流程来回折腾几轮之后整理出来的，适合手里有一台面板机、想给小团队搭个内部仓库的人，也适合已经装完但卡在"钩子不生效""检出没权限"这类问题上的朋友。
1. 面板机上加装 SVN 之前要想清楚的几件事
1.1 SVN 到今天还值得用的场景
先说结论：如果你的仓库里主要是文本代码，且团队全员都用 Git 客户端，那没必要折腾 SVN。但如果仓库里躺着的是设计源文件、Office 文档、编译好的安装包，或者你需要"仓库里某一个子目录单独授权给某个人"这种细粒度控制，SVN 反而更省事。
我总结下来它在这几类场景里特别顺手：一是二进制文件多的项目，SVN 是集中式，检出的是完整工作副本，不会像 Git 那样因为二进制文件反复修改把仓库撑爆（虽然 SVN 也有体积问题，但管理成本低得多）；二是目录级权限，authz文件里写一段路径规则，某个账号就只能读某个子目录，这在给外部协作方开只读权限时非常好用；三是客户端门槛低，装了图形客户端之后，右键"更新""提交"就完事了，不需要理解分支、暂存区、rebase 这些概念；四是可以只检出部分目录，一个大仓库里只拿自己关心的那块，磁盘压力小。
反过来说，SVN 不适合的场景也明确：分支合并频繁、多人并行改同一批文件、需要离线提交、需要 PR 评审流程——这些还是交给 Git。
1.2 面板没有 SVN 模块，意味着什么
宝塔面板的软件商店里有 Nginx、MySQL、PHP、Redis、Docker 这些，但没有 SVN 服务端的一键安装。这不代表不能用，只是意味着装包、建库、启服务、开机自启、防火墙放行这几步都得自己在命令行里做完，面板只负责帮你管端口放行、文件浏览、计划任务这些外围事务。
这里面最容易产生误判的一点是：有人以为装了面板就等于有了完整环境，直接在面板的"终端"里敲svn发现命令不存在，就怀疑面板有问题。其实只是subversion这个包没装而已，yum install subversion或者apt install subversion一条命令解决。面板和系统包管理器是两回事，这一点心里要有数。
另一个误判是端口。面板的"安全"页面管的是系统防火墙规则，你在面板里放行了 3690，不等于firewalld或ufw一定同步了；反过来，命令行里firewall-cmd加了规则，面板列表里可能没显示。排查连接问题时这两处都要看。
1.3 仓库放哪个目录，一开始就该定死
我见过最常见的返工，是仓库路径后期要迁移。一开始随手建在/root/svn或者/home/xxx/svn，后来磁盘满了、或者要做备份策略了、或者面板的网站目录在/www/wwwroot想统一管理，就得停服务、改配置、改钩子里的路径、改客户端地址，一圈下来半小时没了。
我的做法是统一放在/www/svn下，每个项目一个子目录：
/www/svn/ <- svnserve 的根（-r 参数指向这里） project_a/ <- 一个仓库 project_b/ <- 另一个仓库这样做有个直接好处：svnserve -d -r /www/svn之后，客户端地址就是svn://服务器IP/project_a，路径短、好记，而且以后新增仓库不需要重启服务，直接svnadmin create /www/svn/project_c就能用。
顺便把备份目录也规划好，比如/www/backup/svn，后面写备份脚本时直接指向它，不用再临时找地方。
2. svnserve 独立协议还是挂 Apache，选哪个
2.1 两种跑法的本质差别
SVN 服务端对外提供访问，主流就两条路：
第一条，svnserve独立进程 +svn://协议。它自己监听一个端口（默认 3690），不依赖 Web 服务器，配置简单，传输效率高，权限完全靠仓库conf目录下的三个文件控制。
第二条，Apache 加载mod_dav_svn模块 +http://或https://协议。好处是可以复用 80/443 端口、可以套 SSL 证书、可以走反向代理，客户端用浏览器也能直接看仓库内容。代价是要额外装 Apache，而面板上 80 端口通常已经被 Nginx 占了，你得给 Apache 换个端口再反代，配置量和出错面都大一圈。
| 对比维度 | svnserve（svn://） | Apache + mod_dav_svn（http/https） |
|---|---|---|
| 安装复杂度 | 装一个包即可 | 装 Apache 和模块，处理端口冲突 |
| 端口占用 | 独立的 3690 | 复用 80/443 或另开端口 |
| 加密传输 | 原生不加密，需走隧道 | 可挂证书，原生 HTTPS |
| 认证方式 | 仓库内 passwd/authz 文件 | 可用 Apache 的 htpasswd、LDAP 等 |
| 权限粒度 | 路径级，配置直观 | 路径级，但配置分散在 Apache 与 authz |
| 与面板共存 | 无冲突 | 需处理 Nginx 端口与反代 |
| 适合场景 | 内网、小团队、快速上线 | 需要外网 HTTPS 访问、需要统一认证 |
2.2 我的选择和建议
内网环境、团队十几个人以内、没有公网暴露需求，直接用svnserve，别给自己找麻烦。它的配置文件就三个，改完重启（甚至不用重启，因为配置文件是每次连接读取的）就生效。
确实需要 HTTPS 的，也别急着上 Apache，可以考虑用面板的 Nginx 做四层转发把 3690 包一层 TLS，或者干脆只在内网用、外部访问走别的通道。这里展开容易跑偏，不多说。
有一点必须提醒：svn://协议传输的密码是明文（简单混淆），所以绝对不要把这个端口直接开给公网。如果非要从外部访问，务必先解决加密和访问控制的问题，否则等于把仓库钥匙挂在门口。
2.3 端口和防火墙的处理顺序
顺序搞错会很浪费时间。正确的顺序是：先确认服务能起来并监听端口，再去放行防火墙，最后测连通性。
# 1. 看服务是否在监听 ss -lntp | grep 3690 # 2. 放行防火墙（CentOS 系） firewall-cmd --permanent --add-port=3690/tcp firewall-cmd --reload # 3. 放行防火墙（Debian/Ubuntu 系） ufw allow 3690/tcp # 4. 本机自测 svn list svn://127.0.0.1/project_a如果ss看不到 3690 在监听，说明svnserve根本没起来，这时候去查防火墙是白费功夫。反过来，本机svn list svn://127.0.0.1/...通、外部不通，那基本就是防火墙或云厂商安全组的问题，面板的"安全"页面里要把 3690 加进去——注意，云服务器的安全组是两层，面板管不到云控制台那一层。
3. 装包、建库，以及svnadmin create之后那堆目录
3.1 装包与版本确认
CentOS / 麒麟 / 统信这类yum系：
yum install -y subversionDebian / Ubuntu 这类apt系：
apt update apt install -y subversion装完立刻验证，别等到配完权限才发现装的是个残包：
svnserve --version svn --version --quiet正常情况下svnserve --version会输出类似1.10.x或1.14.x的版本号，以及支持的仓库后端（FSFS）。如果提示command not found，检查是不是装到了非默认路径，或者PATH被面板的环境改过——用绝对路径/usr/bin/svnserve --version再试一次。
提示：老系统的软件源里可能还是 1.7、1.8 这种很旧的版本。旧版本能跑，但如果客户端是新版，某些特性（比如
svn:auto-props的自动属性设置）行为会有差异。条件允许的话优先用 1.10 以上的版本。
3.2 建仓库并读懂目录结构
mkdir -p /www/svn svnadmin create /www/svn/project_a ls -l /www/svn/project_a你会看到这么几个东西：
| 名称 | 作用 |
|---|---|
conf/ | 配置目录，里面是svnserve.conf、passwd、authz三个文件 |
db/ | 真正存数据的地方，FSFS 格式，一堆数字编号的文件 |
hooks/ | 钩子脚本模板，提交前后触发的动作都放这里 |
locks/ | 锁文件目录，svn lock用 |
format | 仓库格式版本号，一个纯数字文件 |
README.txt | 官方说明，可以不管 |
这里有个很多人第一次会懵的点：db/里看不到任何"文件"。SVN 不是把原始文件按原样存进去的，而是把每次提交存成一个新的版本号目录（db/revs/0、db/revs/1……），文件内容以增量或全文形式存在里面。所以千万别想着直接去db里拷贝文件，那是自找麻烦，要导出用svn export，要备份用svnadmin hotcopy或svnadmin dump。
3.3 先把仓库跑起来，再配权限
我的习惯是先让仓库以匿名可读的状态跑通，确认服务和路径没问题，再去收紧权限。这样出问题时容易定位是"服务/路径"的问题还是"认证"的问题。
# 临时启动，前台看日志 svnserve -d -r /www/svn --listen-port 3690 # 验证 svn list svn://127.0.0.1/project_a如果这一步就报错，先别动conf里的东西，去看ps aux | grep svnserve和错误输出。/ 常见的是-r参数路径写错，或者 3690 被别的进程占了。
跑通之后，把服务做成开机自启，别依赖手动敲命令。用 systemd 最稳：
# /etc/systemd/system/svnserve.service [Unit] Description=Subversion Server After=network.target [Service] Type=forking ExecStart=/usr/bin/svnserve -d -r /www/svn ExecStop=/usr/bin/pkill svnserve Restart=on-failure [Install] WantedBy=multi-user.targetsystemctl daemon-reload systemctl enable --now svnserve systemctl status svnserve不想写 unit 文件的，也可以在面板的"计划任务"里加一条开机执行的 shell，内容就是svnserve -d -r /www/svn。功能一样，只是查状态没那么方便。
4. 三个配置文件：passwd、authz、svnserve.conf 的写法与雷区
4.1svnserve.conf：最容易栽在缩进上
这个文件是总开关，需要改的通常就四五项：
[general] anon-access = none auth-access = write password-db = passwd authz-db = authz realm = project_a含义分别是：匿名用户无任何权限、认证用户可写、密码文件是passwd、权限文件是authz、认证域名为project_a。
这里有一个百分之百会遇到的坑：配置项前面不能有空格。原始文件里所有项目都是被#注释掉的，而且注释符后面往往跟着一个空格，很多人习惯性地把#删掉、保留了空格，结果启动或连接时报：
svnserve: /www/svn/project_a/conf/svnserve.conf:20: Option expected这个报错的意思就是"这一行我读不懂"。解决办法很简单：确保每一行配置都从行首第一个字符开始，前面不能有任何空白。改完可以用cat -A svnserve.conf | grep -n '^ '检查有没有残留的空格行。
另外password-db和authz-db的路径是相对于conf目录的，写passwd就够，别写成绝对路径（写绝对路径也能用，但一旦迁移仓库就全废）。
4.2passwd：密码是明文的，这点必须接受
[users] zhangsan = Passw0rd_2024 lisi = another_pass格式就是用户名 = 密码，等号两边可以有空格，但用户名里不要有中文和空格。密码以明文存储，这是 SVN 的设计，改不了。所以：
- 不要用和别的系统一样的密码；
- 仓库目录的权限要收紧，
conf/passwd不能是 777； - 账号不要给太多人共用，出问题无法追溯。
加完账号不需要重启服务，下次连接自动生效。
4.3authz：路径写法决定你能不能提交
这个文件是权限的核心，也是最容易写错的地方。基础结构是这样：
[groups] dev = zhangsan,lisi guest = wangwu [/] * = @dev = rw zhangsan = rw [/docs] @dev = rw @guest = r [/assets] @dev = rw @guest = r * = r几个关键点：
第一，路径的起点取决于svnserve -r指向哪里。我这里是-r /www/svn，所以[/]指的是project_a这个仓库的根，[/docs]指的是project_a/docs。如果你的-r指向的是/www/svn/project_a，那路径写法又不一样。这块一定要和自己的启动参数对齐，否则会出现"明明给了权限还是 403"。
第二，*表示"所有用户"，包括未登录的匿名用户；$anonymous专指匿名，$authenticated专指已登录。上面[/]里写了* =（等号右边留空），意思就是默认谁都没权限，然后单独给@dev和zhangsan开rw。这种"先全禁、再逐个放"的写法最安全。
第三，权限只有r、rw、空三种。写w但没写r是无效的，SVN 会当成没有权限。要给写权限就必须给rw。
第四，权限是继承且就近覆盖的。父目录给了rw，子目录会自动继承；在子目录里重新声明就会覆盖。所以想收回某个子目录的写权限，直接在那个子目录下再写一行即可。
第五，用户名大小写敏感。zhangsan和ZhangSan是两个账号，别问我怎么知道的。
5. 客户端检出与日常操作的真实流程
5.1 检出地址怎么写
服务跑起来、权限配好之后，客户端地址就是：
svn://你的服务器IP/project_a命令行检出：
svn checkout svn://192.168.1.100/project_a /data/work/project_a \ --username zhangsan --password Passw0rd_2024图形客户端里填入同样的地址，第一次会弹认证框。这里有个细节：如果你改过realm，客户端缓存的旧凭据会失效，需要清缓存。Windows 上在%APPDATA%\Subversion\auth目录，Linux 在~/.subversion/auth，删掉重试即可。这一条能解决一大半"密码明明对但一直提示认证失败"的问题。
5.2add之后必须commit
这是新手最高频的困惑："我把文件放进目录了，服务器上怎么没有？"
因为 SVN 的检出目录是一份工作副本，你在里面新建的文件对这个副本来说是"未版本控制的"（unversioned）。必须显式svn add告诉 SVN 要跟踪它，再svn commit推上去：
cd /data/work/project_a cp ~/design.psd ./docs/ svn status # 会看到 ? docs/design.psd svn add docs/design.psd # 状态变成 A svn commit -m "新增设计稿初版" # 提交后才到服务器注意svn status的符号含义，这是日常排查的核心：
| 符号 | 含义 |
|---|---|
? | 未纳入版本控制，服务器上没有 |
A | 已 add，待提交 |
M | 已修改，待提交 |
D | 已删除，待提交 |
! | 文件丢失（本地删了但没svn delete） |
C | 冲突，必须先解决 |
!这个状态特别容易出问题：有人直接在文件管理器里按了删除键，然后svn commit发现服务器上文件还在。正确做法是用svn delete 文件名删，或者删完后补一个svn delete --keep-local之类的操作把状态登记上。
5.3 忽略文件、还原误操作、看历史
忽略文件：日志、临时文件、编译产物不该进仓库。有两种做法，一种是在客户端给目录设属性：
svn propset svn:ignore -F .svnignore . svn commit -m "设置忽略规则".svnignore里一行一个模式，比如*.log、node_modules、*.tmp。另一种是在服务端给仓库配svn:global-ignores（SVN 1.8+），一次配置全局生效。注意：忽略规则只对"尚未纳入版本控制"的文件生效，已经提交过的文件加忽略是没用的，得先svn delete再提交。
还原误操作：
svn revert 文件名 # 撤销本地未提交的修改 svn revert -R . # 递归撤销整个目录 svn update # 把服务器最新版拉下来revert是不可逆的，撤销掉的本地修改找不回来，动手前想清楚。
看历史：
svn log -l 10 # 最近 10 条提交记录 svn log -v -r 15 # 第 15 个版本的详细改动文件列表 svn diff -r 14:15 # 两个版本之间的差异 svn cat -r 15 path/file # 直接看某个版本的文件内容这几个命令在"谁把我的文件改了"这类场景里非常好用。
6. 提交后自动更新：钩子脚本为什么不生效
6.1 钩子的执行机制先搞清楚
hooks目录里有一堆.tmpl模板文件，去掉.tmpl后缀就变成生效的脚本。最常用的是post-commit，它在每次提交成功之后被服务端执行。
模板长这样：
#!/bin/sh # PRE-COMMIT-WORKING-COPY-UPDATE (可删除) REPOS="$1" REV="$2"$1是仓库的绝对路径，$2是刚提交的版本号。注意这个脚本执行的时候没有终端、没有登录 shell、环境变量极简，这是所有坑的根源。
6.2 一份能用的post-commit
我的写法是这样的，先把仓库代码更新到网站目录：
#!/bin/bash export LANG=zh_CN.UTF-8 export LC_ALL=zh_CN.UTF-8 REPOS="$1" REV="$2" SVN=/usr/bin/svn WEB=/www/wwwroot/mysite LOG=/www/svn/hook.log echo "===== $(date '+%F %T') rev=$REV =====" >> $LOG # 首次：如果目标目录还不是工作副本，做一次检出 if [ ! -d "$WEB/.svn" ]; then $SVN checkout svn://127.0.0.1/project_a "$WEB" \ --username autoupdate --password 'xxxxxx' \ --non-interactive --no-auth-cache >> $LOG 2>&1 else $SVN update "$WEB" \ --username autoupdate --password 'xxxxxx' \ --non-interactive --no-auth-cache >> $LOG 2>&1 fi # 修正文件属主，避免网站读不到 chown -R www:www "$WEB" echo "done at $(date '+%F %T')" >> $LOG几个必须做的动作，缺一不可：
第一，给执行权限。
chmod +x /www/svn/project_a/hooks/post-commit忘了这一步，钩子静默不执行，日志里什么都没有，你会怀疑人生。
第二，脚本里所有命令都用绝对路径。svn写成/usr/bin/svn，不然钩子运行环境里PATH可能只有/usr/local/sbin:/usr/local/bin，找不到svn。
第三，文件必须是 LF 换行。如果你是在 Windows 上编辑好再传上去的，脚本里会带\r，执行时报bad interpreter: No such file or directory，看着像路径错，其实是换行符问题。修复：
sed -i 's/\r$//' /www/svn/project_a/hooks/post-commit或者用dos2unix处理一下。
第四，认证信息要显式给。钩子里跑svn update是个新的进程，没有客户端缓存可用。要么像上面那样在命令行带账号密码，要么在仓库里建一个专用于自动更新的账号，权限只给读。别给这个账号写权限，纯粹用于拉取。
6.3 文件属主：最常见的"更新成功但网站没变"
svnserve通常以 root 身份运行，钩子里的svn update也是 root 执行的，所以更新下来的文件属主是root:root。而面板上的网站（Nginx 或 PHP-FPM）是以www身份跑的，遇到root属主、权限644的文件，读是可以读的，但如果程序需要写（上传目录、缓存、日志），就会各种权限报错，表现为"页面白屏""上传失败"。
处理方法就是脚本末尾那一行chown -R www:www，或者在 update 时用sudo -u www /usr/bin/svn update ...让整个过程以www身份执行。后者更干净，但要求www用户对目标目录和工作副本有完整权限，配置稍麻烦。
还有一种更隐蔽的情况：目录权限是 755、文件是 644，但父目录没有x权限，导致 Nginx 打不开文件。这个查起来很费劲，建议统一用chown -R www:www && find . -type d -exec chmod 755 {} \;兜底。
6.4update还是export，这是个设计选择
用svn update更新网站目录，好处是增量、快，坏处是网站目录里会留下.svn目录，而且可能残留历史文件。
用svn export --force的方式则是每次全量覆盖导出，目录干净，但慢——尤其是文件多的时候。
| 方式 | 速度 | 目录干净度 | 适用 |
|---|---|---|---|
svn update | 快，增量 | 带.svn，可能残留旧文件 | 迭代频繁、文件多 |
svn export --force | 慢，全量 | 干净，无版本元数据 | 文件少、要求目录纯净 |
我的习惯是用update，然后把.svn目录通过 Nginx 配置禁掉访问：
location ~ /\.svn { deny all; }既保证速度，又不泄露版本信息。如果是纯静态发布、文件不多，export更省心，不用管残留。
6.5 钩子执行了但没效果，怎么一步步查
这个排查链路我走过不止一次，按顺序走基本能定位：
- 看日志文件。上面脚本里写了
$LOG，先tail -50 /www/svn/hook.log。如果日志里只有===== 时间 rev=xx =====没有后续，说明卡在svn update这一步，多半是认证或权限。如果连时间戳都没有，说明钩子压根没被执行。 - 确认钩子有执行权限，
ls -l hooks/post-commit看是不是-rwxr-xr-x。 - 手动模拟执行。这是最关键的一步：
cd /tmp /www/svn/project_a/hooks/post-commit /www/svn/project_a 20把20换成实际的版本号。手动跑能复现问题，就能看到完整报错；手动跑成功但提交时不成功，基本就是环境变量或权限差异。
- 看服务端有没有报错。
svnserve默认不输出详细日志，可以临时前台启动观察：
pkill svnserve svnserve -d -r /www/svn --foreground --log-file /tmp/svn.log- 确认提交真的成功了。有时候客户端提示失败，但文件其实已经部分提交，钩子自然不触发。用
svn log -l 1看最新版本号是不是你刚才那次。
7. 那些绕不开的报错：从认证失败到 locked
7.1Authorization failed和Authentication failed不是一回事
这两个报错长得像，含义完全不同，混淆了会多花一小时。
Authentication failed：账号密码不对。检查passwd文件里有没有这个账号、密码有没有多余空格、大小写对不对、客户端缓存的旧凭据有没有清掉。Authorization failed：账号密码对，但这个人没有这个路径的权限。问题出在authz。
authz排查的顺序是：先确认svnserve.conf里authz-db = authz没写错名字；再确认authz里路径起点和-r参数一致；最后确认用户的组归属写对了（@dev里的名字必须和passwd里完全一致，包括大小写）。
还有一种情况：authz文件里写了 BOM 头或者从 Windows 复制过来带了\r，会导致整个文件解析异常，表现为所有人权限都乱。用file authz看一下编码，或者直接sed -i 's/\r$//' authz处理掉。
7.2E155004: Working copy locked
这个报错的意思是工作副本被锁住了，通常是上一次操作（commit、update、switch）中途被打断——比如网断了、终端被关了、磁盘满了。
标准解法：
svn cleanupcleanup会清理工作副本里的锁文件、恢复中断的事务。如果cleanup也失败，就得手动删除锁文件：
find . -name "*.lock" -o -name "lock" | grep .svn rm -f .svn/lock svn cleanup注意，删除.svn/lock只在确认没有其他进程正在操作这个工作副本时才安全，多人共用同一份工作副本本身就违反 SVN 的用法（每个人应该有自己的工作副本）。
7.3Can't open file 'db/txn-current-lock': Permission denied
这是服务端仓库目录权限问题。svnserve以某个身份运行，需要对仓库目录有读写权限。检查：
ls -ld /www/svn /www/svn/project_a /www/svn/project_a/db如果svnserve是 root 跑的，一般不会有这个问题。但如果是为了安全用普通用户跑（推荐做法），那就得chown -R 该用户:该用户 /www/svn。
提到安全，还有一个经常被忽略的东西：SELinux。CentOS 系默认开启，它会阻止svnserve往非标准路径写文件，表现为所有提交都失败但权限看着都对。临时验证：
getenforce # 看是不是 Enforcing setenforce 0 # 临时关闭，仅用于定位问题确认是 SELinux 导致的，正确做法是加策略而不是长期关闭：
chcon -R -t svnserve_content_t /www/svn或者用semanage fcontext持久化规则。如果不是很熟悉，明确记录"这台机器 SELinux 已关闭"也是一种可接受的选择，但要知道这个决定的影响。
7.4 中文文件名和大文件
中文文件名：服务端和客户端编码不一致时，svn status会显示一坨乱码或者问号，commit后服务器上的文件名也可能变形。解决办法是在钩子脚本和系统层面统一 UTF-8：
export LANG=zh_CN.UTF-8 export LC_ALL=zh_CN.UTF-8客户端的~/.subversion/config里确认[miscellany]段的enable-auto-props以及本地化设置正常。Windows 客户端早期版本在 GBK 和 UTF-8 之间转换有问题，尽量用较新的图形客户端。
大文件：SVN 对单个大文件的支持不如 Git LFS 那种方案，几十上百 MB 的 PSD 反复提交会让db目录迅速膨胀。两个建议：一是加svn:needs-lock属性，避免多人同时改同一个大文件导致二进制冲突；二是定期用svnadmin pack压缩仓库，以及监控磁盘。
8. 备份、升级和长期维护的几个习惯
8.1 两种备份方式，各有用途
svnadmin hotcopy：整库物理拷贝，快，适合每日全量备份，可以在线执行。
svnadmin hotcopy /www/svn/project_a /www/backup/svn/project_a_$(date +%F)svnadmin dump：导出成可读的版本流，体积小，可以按版本区间导出，适合迁移和归档。
svnadmin dump /www/svn/project_a -r 1:100 --incremental > /www/backup/svn/a_1_100.dump恢复：svnadmin load /www/svn/new_repo < a_1_100.dump。
我一般在面板的"计划任务"里挂一个每天凌晨的 shell 脚本，做hotcopy加保留最近 7 天，再每周做一次dump存到别的分区或者对象存储。脚本里记得处理"目标目录已存在"的情况，hotcopy不会覆盖已存在的目录。
8.2 磁盘、日志与仓库体积
db/revs和db/revprops会随着提交持续增长，光看目录大小看不出问题，但磁盘满的时候很突然。建议：
- 面板里设一个磁盘占用告警阈值；
- 每月看一下
du -sh /www/svn/*； - 对不再需要的历史大文件，不要直接删
db里的东西，那是灾难，正确处理是用svnadmin dump过滤后重建仓库； - 钩子日志要轮转，别让
hook.log无限长下去。
8.3 一个容易被忽略的点：工作副本的pristine缓存
SVN 1.7 以后，每个工作副本的.svn/pristine目录会存一份文件原文副本，用于快速比较。这意味着工作副本占用的磁盘空间大概是实际文件的两倍。服务器上如果有自动更新的工作副本，长期下来这块会不小，做磁盘规划时要把这个算进去。
到这儿，整套流程就算闭环了：装包、建库、配权限、开端口、启服务、客户端检出、钩子自动更新，再加上排错和备份。真的按照这个顺序走一遍，中间大概率还是会遇到一两个报错，但那都属于"照着日志改一行"的级别。我自己的体会是，SVN 这套东西难的不是配置本身，而是搞不清出问题时该先看哪一层——是先看进程、先看端口、先看认证、还是先看钩子日志。把这几个层次在心里排好序，遇到报错就不会乱试，一次定位、一次解决，比反复重启服务有效得多。另外强烈建议第一次配库的时候用svn list svn://127.0.0.1/仓库名做本机验证，把"服务本身"和"网络与权限"彻底拆开，这一步能省掉后面一大半的迷惑。
