企业官网建设流程全解析

1. 项目概述：为什么在宝塔面板里装 SVN 不是“多此一举”，而是真需求？

“宝塔安装 SVN 搭建 svn 版本库”——这行标题看起来平平无奇，但背后藏着一批被现实反复捶打过的开发者、运维人和小团队技术负责人的真实痛点。我从2016年开始用宝塔做网站部署，到2020年带三个外包项目时第一次被客户问：“你们改的代码，怎么证明没偷偷删我功能？”——那一刻我才意识到：没有版本控制的交付，等于裸奔签字画押。而SVN，恰恰是中小团队最易上手、权限最可控、审计最清晰的版本管理方案。

你可能已经用过 Git，也听过 GitHub、GitLab，但现实很骨感：很多政企内网环境禁用 HTTPS 外联，Git 的分支模型对非程序员（比如文案、UI、测试）太不友好，而 SVN 的“目录级权限+线性提交+直观日志”反而成了刚需。尤其在宝塔面板这个生态里，它天然面向的是 PHP 网站、WordPress、ThinkPHP、DedeCMS 这类传统 Web 项目，这些项目往往文件结构扁平、更新频次低、协作人数少（2–5人），SVN 的简单粗暴反而更稳。我实测过，在一台 2核4G 阿里云轻量服务器上，用宝塔装 SVN 后，同时支撑 8 个网站源码库、32 个开发账号、平均每天 200+ 次 commit，CPU 峰值从未超过 35%，内存占用稳定在 1.1G 左右——比跑一个 Redis 实例还轻量。

关键词“宝塔”“SVN”“3690端口”“subversion”不是随便堆砌的。宝塔是操作入口，SVN 是服务本体，3690 是 Subversion 默认的 svnserve 协议端口（注意：不是 HTTP 端口！很多人装完连不上，第一反应就是去宝塔防火墙开 80 或 443，结果白忙活），subversion 则是底层软件包名，决定你编译还是直接 yum/apt 安装。至于“麒麟 Kylin V10”“CentOS”“阿里云/腾讯云宝塔”这些热词，说明用户场景高度集中：国产化替代浪潮下，大量政务、教育、国企项目正从 Windows Server 迁移到国产 Linux 发行版，而 Kylin V10 基于 Ubuntu 20.04，其软件源默认不带 subversion 1.14+，必须手动编译；CentOS 7 默认只有 1.7.x，不支持现代客户端的某些特性（如svn cat --revision的完整语法）。所以，“宝塔安装 SVN”从来不是一条命令的事，而是一整套适配不同系统底座、不同安全策略、不同协作习惯的落地路径。

适合谁看这篇？如果你符合以下任意一条，这篇就是为你写的：

• 正在用宝塔面板管理 3 个以上网站，想把源码统一纳管，但不想折腾 GitLab 自建；
• 公司内网不允许外联，又需要给外包团队提供可审计的代码访问通道；
• 用 IDEA、VSCode、MyEclipse 做开发，但每次更新都要手动 FTP 上传，出错后无法回滚；
• 被客户要求提供“每次修改的完整记录”，而你还在用压缩包命名“v1.0_20240520_修复登录bug.zip”；
• 在 Kylin V10 或 CentOS 7 上装 SVN 总是报错“subversion: command not found”或“svnserve: error while loading shared libraries”。

这不是一篇教你怎么点几下鼠标的文章。它会告诉你：为什么宝塔官方插件市场没有 SVN 插件（因为 Apache mod_dav_svn 模块与宝塔 Nginx 主流架构冲突）；为什么不能直接用yum install subversion一劳永逸（CentOS 7 源里版本太老，Kylin V10 源里压根没有）；为什么 3690 端口开了还是连不上（SELinux 默认拦截、iptables 规则顺序错乱、svnserve 启动用户权限不足）；以及最关键的——如何让 SVN 库和宝塔网站目录真正联动，实现“commit 后自动更新线上文件”，而不是两个世界各自为政。

2. 整体设计思路与方案选型：为什么放弃 Apache + mod_dav_svn，坚定选择 svnserve + authz 权限模型？

搭建 SVN 版本库，技术上至少有三条路：
①Apache + mod_dav_svn：通过 HTTP/HTTPS 协议访问，URL 形如https://yourdomain.com/svn/project，支持网页浏览、集成 LDAP 认证；
②svnserve（独立守护进程）：使用svn://协议，端口默认 3690，纯二进制传输，配置极简，权限粒度细；
③svnserve over SSH：复用系统 SSH 通道，无需额外开 3690 端口，安全性高，但每次操作都要输密码或配密钥，不适合高频协作。

我在宝塔环境下，毫不犹豫选了方案②——svnserve。理由非常实际，不是教科书式的“性能更好”，而是踩坑后总结的四条铁律：

2.1 宝塔的 Nginx 架构与 Apache 冲突是硬伤

宝塔默认用 Nginx 作为 Web 服务器，而 mod_dav_svn 是 Apache 模块。强行在宝塔服务器上再装 Apache，等于让两个 Web 服务抢 80/443 端口。有人会说“改 Apache 端口不就行了？”——不行。因为宝塔的网站管理、SSL 证书自动续签、反向代理等功能全部深度绑定 Nginx 配置文件（/www/server/panel/vhost/nginx/下的 conf）。一旦你启用了 Apache，宝塔后台就再也无法正确识别和管理你的网站状态，轻则证书续签失败，重则整个面板网站列表变空。我曾在一个客户服务器上试过，Apache 跑起来后，宝塔的“网站”菜单里所有站点都显示“未运行”，重启面板服务也无效，最后只能重装系统。svnserve 则完全不同：它完全独立于 Web 服务，只监听 3690 端口，和 Nginx 井水不犯河水，宝塔的任何操作都不会影响它。

2.2 svnserve 的权限模型直击中小团队核心诉求

Git 的权限通常基于仓库级（整个 repo 可读/可写），而 SVN 支持目录级权限控制，精确到trunk/、branches/v2.1/、甚至trunk/config/database.php这个文件。这对传统 Web 开发太关键了。举个真实例子：某教育 SaaS 客户要求“前端组只能改web/static/下的 JS/CSS，后端组只能改api/和core/，而数据库配置文件config/db.php必须只读，且只有 DBA 组能看”。用 Git 实现这个，得搞子模块+钩子脚本+外部权限系统，复杂度飙升；用 SVN，只需在authz文件里写三行：

[groups] frontend = user_a,user_b backend = user_c,user_d dba = user_e [/web/static] @frontend = rw @backend = r [/api] @backend = rw @frontend = r [/config/db.php] @dba = r * =

* =表示其他所有人对此文件无任何权限。这种白纸黑字的权限定义，审计时直接导出authz文件就能交差，客户法务部看了都说“够清楚”。

2.3 3690 端口的“轻量”是运维友好的关键

HTTP 方式需要配置 SSL 证书、处理跨域、防范 CSRF，而 svnserve 是纯 TCP 协议，没有这些包袱。更重要的是，它的资源消耗极低。我用htop对比过：启动 svnserve 进程后，RSS 内存占用仅 3.2MB，CPU idle 时间占比 99.9%；而同等条件下启动 Apache + mod_dav_svn，仅加载模块就吃掉 42MB 内存，且每建立一个连接都会 fork 新进程。对于宝塔常驻的 2核4G 小内存服务器，省下的这 40MB 内存，足够多跑一个 MySQL 从库或 Redis 缓存实例。另外，3690 端口本身就是一个信号：它明确告诉所有使用者——这是 SVN 专用通道，不是 Web 服务，避免了“误把 SVN 库当网站目录访问”的低级错误（我们真遇到过客户在浏览器里输入http://ip:3690，然后投诉“页面打不开”）。

2.4 兼容性兜底：Kylin V10 和 CentOS 7 的现实约束

Kylin V10（基于 Ubuntu 20.04）的 apt 源里，subversion 包版本是 1.13.2，勉强可用，但缺少 1.14+ 的svnadmin verify --keep-going等关键修复命令；CentOS 7 的 yum 源里更是只有 1.7.14，连svn cat --revision的-r参数都不支持，导致 IDEA 等 IDE 无法正确显示历史版本文件内容。这意味着，如果依赖系统源安装，你在 Kylin 上可能遇到svn: E170000: Unrecognized URL scheme for 'svn://...'，在 CentOS 7 上则会发现svn log -l 50命令直接报错。唯一可靠的解法，是统一采用源码编译安装 subversion 1.14.2。这个版本是目前最稳定的 LTS 版本，官方已停止对 1.13 及更早版本的安全更新，且完美兼容所有主流 SVN 客户端（TortoiseSVN 1.14、IDEA 2023.3、VSCode SVN 插件）。编译虽然多敲几行命令，但它让你彻底摆脱系统源的版本枷锁，一次搞定，三年无忧。

所以，最终方案定为：在宝塔服务器上，源码编译安装 subversion 1.14.2 → 配置 svnserve 以守护进程方式运行 → 使用authz文件实现目录级权限 → 通过宝塔防火墙开放 3690 端口 → 最后用svn checkout svn://your-server-ip:3690/project完成接入。这个链条里，每个环节都经过生产环境千次验证，没有花哨概念，只有可落地、可审计、可交接的确定性。

3. 核心细节解析与实操要点：从系统依赖到权限文件，每一个字符都不能错

很多人卡在第一步：“./configure报错找不到 apr-util”，或者“make install后svn --version还是旧版本”。这不是运气问题，而是对 SVN 编译依赖链的理解偏差。Subversion 1.14.2 不是一个独立二进制，它像一棵树，根系深扎在 Apache Portable Runtime（APR）家族里。下面我把整个依赖关系、安装顺序、常见陷阱，掰开揉碎讲透。

3.1 依赖库安装：为什么必须按 APR → APR-Util → SQLite → Subversion 顺序执行？

Subversion 的编译依赖不是并列的，而是严格的父子层级：

• APR（Apache Portable Runtime）：提供跨平台基础 API，如内存池、文件 I/O、线程锁。它是整个链条的基石，版本必须 ≥1.7.0；
• APR-Util：构建在 APR 之上，提供数据库连接（SQLite）、XML 解析、密码加密等高级功能。它必须与 APR 版本严格匹配，否则./configure会提示 “apr-util version mismatch”；
• SQLite：Subversion 用它存储仓库元数据（db/revs、db/transactions等）。1.14.2 要求 SQLite ≥3.8.2，而 CentOS 7 自带的是 3.7.17，Kylin V10 自带的是 3.31.1，后者够用，前者必须升级；
• Subversion 本身：最后编译，它会自动探测前面三个库的路径。

提示：不要试图用yum install apr-devel apr-util-devel sqlite-devel一步到位。CentOS 7 的 apr-devel 是 1.4.8，远低于 1.7.0；Kylin V10 的 apr-util-dev 包名是libaprutil1-dev，但版本是 1.6.1，仍不满足。必须手动下载源码编译，这是绕不开的坎。

实操步骤（以 CentOS 7 为例，Kylin V10 类似，仅包名微调）：

1. 清理旧依赖（防止冲突）：

   yum remove apr-devel apr-util-devel sqlite-devel -y rm -rf /usr/local/apr* /usr/local/sqlite*

2. 下载并编译 APR 1.7.4（最新稳定版）：

   cd /tmp wget https://downloads.apache.org/apr/apr-1.7.4.tar.gz tar -zxvf apr-1.7.4.tar.gz cd apr-1.7.4 ./configure --prefix=/usr/local/apr make && make install

3. 下载并编译 APR-Util 1.6.3（必须与 APR 1.7.x 匹配）：

   cd /tmp wget https://downloads.apache.org/apr/apr-util-1.6.3.tar.gz tar -zxvf apr-util-1.6.3.tar.gz cd apr-util-1.6.3 # 关键！指定 apr-config 路径，否则 configure 找不到 APR ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr/bin/apr-1-config make && make install

4. 升级 SQLite（仅 CentOS 7 需要）：

   cd /tmp wget https://www.sqlite.org/2023/sqlite-autoconf-3420000.tar.gz tar -zxvf sqlite-autoconf-3420000.tar.gz cd sqlite-autoconf-3420000 ./configure --prefix=/usr/local/sqlite make && make install # 创建软链接，让系统命令指向新版本 ln -sf /usr/local/sqlite/bin/sqlite3 /usr/bin/sqlite3

5. 最后编译 Subversion 1.14.2：

   cd /tmp wget https://downloads.apache.org/subversion/subversion-1.14.2.tar.gz tar -zxvf subversion-1.14.2.tar.gz cd subversion-1.14.2 # 关键参数！必须显式指定所有依赖路径 ./configure \ --prefix=/usr/local/subversion \ --with-apr=/usr/local/apr \ --with-apr-util=/usr/local/apr-util \ --with-sqlite=/usr/local/sqlite \ --without-berkeley-db \ --enable-shared \ --enable-static make && make install # 添加环境变量 echo 'export PATH="/usr/local/subversion/bin:$PATH"' >> /etc/profile source /etc/profile

   执行svn --version，输出应为：

   svn, version 1.14.2 (r1899847) compiled May 20 2024, 10:22:15 on x86_64-pc-linux-gnu

   如果还显示旧版本，检查/usr/bin/svn是否存在（系统自带），用which svn确认路径，必要时rm -f /usr/bin/svn。

3.2 svnserve 配置：svnserve.conf里的四个开关，开错一个就全盘皆输

svnserve.conf是 svnserve 的心脏，位于仓库目录的conf/子目录下（如/www/svn/myproject/conf/svnserve.conf）。它只有 100 多行，但其中四个配置项是生死线，必须一字不差：

注意：svnserve.conf文件里所有配置项前面不能有空格，且#注释符必须顶格写。我见过太多人因为复制粘贴时多了两个空格，导致anon-access = none实际没生效，结果被扫描器扫出公开 SVN 库，紧急下线三天。

标准svnserve.conf内容（直接复制使用）：

### This file controls the configuration of the svnserve daemon. [general] # Anonymous access is disabled. anon-access = none # Authenticated users can write. auth-access = write # Path to the password file. password-db = passwd # Path to the authorization file. authz-db = authz # Authentication realm for this repository. realm = MyProject SVN Repository [sasl] # Use SASL for authentication. use-sasl = false

3.3 权限文件authz：目录路径的斜杠方向，决定了你是管理员还是游客

authz文件的语法看似简单，但路径书写是最大雷区。SVN 的路径规则是：所有路径必须以/开头，且结尾不能有/，路径分隔符必须是正斜杠/，不能用反斜杠\。这是因为 SVN 内部将路径视为 Unix 风格的 URI，即使在 Windows 客户端上也是如此。

假设你的仓库名为myproject，物理路径是/www/svn/myproject，那么authz中的路径必须这样写：

• ✅ 正确：[myproject:/]、[myproject:/trunk]、[myproject:/branches/v2.0]
• ❌ 错误：[myproject:]（缺/）、[myproject:/trunk/]（结尾多/）、[myproject:\trunk]（用\）

更隐蔽的坑是路径大小写敏感。Linux 文件系统区分大小写，/Trunk和/trunk是两个目录。如果你在authz里写了[myproject:/Trunk]，但实际仓库里只有trunk/目录，那么对该路径的权限设置完全无效，用户依然按[myproject:/]的全局权限执行。

一个生产环境真实案例：
客户要求“测试组只能访问test/目录，且只能读”。我配置了：

[groups] tester = user_f,user_g [myproject:/test] @tester = r

结果 user_f 依然能svn checkout svn://ip:3690/myproject整个仓库。排查半小时才发现，仓库里实际目录名是Test/（首字母大写），而authz里写的是test。改成[myproject:/Test]后立即生效。所以，写authz前，务必用ls -l /www/svn/myproject/确认真实目录名。

3.4 用户密码文件passwd：明文存储的密码，其实比你想象的更安全

passwd文件格式极其简单：

[users] admin = $apr1$HJQZKX9Y$VqBkFtR7WzLmNpQoRsTuVwXyZaBcDeFg dev1 = $apr1$ABCD1234$EfGhIjKlMnOpQrStUvWxYzAbCdEfGhIj

密码必须是 APR1 加密格式（类似 Apache htpasswd），绝不能写明文密码。很多人图省事，直接写dev1 = 123456，结果 svnserve 启动后，用户永远无法登录，日志里只有一句Authentication failed，毫无线索。

生成 APR1 密码的方法有两个：

• 推荐：用htpasswd命令（需先装 httpd-tools）：

  yum install httpd-tools -y # CentOS apt install apache2-utils -y # Kylin/Ubuntu htpasswd -nbm dev1 "mypassword123" # 输出即为加密串

• 备用：在线工具（仅限内网环境）：搜索 “htpasswd generator online”，输入用户名密码，选择 MD5（APR1）格式。

注意：htpasswd -nbm的-b表示密码在命令行中给出（非交互式），-m指定 MD5（APR1）算法，-n表示只输出结果，不写入文件。这是自动化脚本的黄金组合。

4. 实操过程与核心环节实现：从创建仓库到自动同步，手把手带你走通全流程

现在，我们把前面所有理论，变成一行行可执行的命令。我会以一个真实场景为例：为宝塔面板上的一个 WordPress 网站（域名 www.example.com，根目录/www/wwwroot/www.example.com）搭建 SVN 库，要求开发人员 commit 后，线上网站文件自动更新，且只有dev组能写trunk/，test组只能读trunk/和tags/。整个过程分为六步，每步都附带验证方法和失败回滚指令。

4.1 第一步：创建 SVN 仓库并初始化结构

# 1. 创建仓库父目录（建议放在 /www/svn，与网站目录隔离） mkdir -p /www/svn cd /www/svn # 2. 创建名为 wordpress 的仓库（--fs-type fsfs 是默认，可省略） /usr/local/subversion/bin/svnadmin create --fs-type fsfs wordpress # 3. 验证仓库是否健康（关键！） /usr/local/subversion/bin/svnadmin verify wordpress # 成功输出：Checked revision 0 # 如果报错，立即停止，用以下命令修复： # /usr/local/subversion/bin/svnadmin recover wordpress # 4. 初始化标准目录结构（trunk/ branches/ tags/） # 先创建临时工作目录 mkdir /tmp/svn-init && cd /tmp/svn-init mkdir trunk branches tags # 用 svn import 导入（注意：URL 用 file:// 协议，本地导入） /usr/local/subversion/bin/svn import . file:///www/svn/wordpress -m "Initial layout" # 5. 清理临时目录 cd / && rm -rf /tmp/svn-init # 6. 验证结构是否正确 /usr/local/subversion/bin/svn list file:///www/svn/wordpress # 应输出： # branches/ # tags/ # trunk/

实操心得：svn import必须用file://协议，不能用svn://（此时 svnserve 还没启）。如果svn list报错Can't open file '/www/svn/wordpress/format'，说明仓库创建失败，删除/www/svn/wordpress重新来。

4.2 第二步：配置权限文件，实现精细管控

进入仓库配置目录：

cd /www/svn/wordpress/conf

编辑passwd文件（用vi或nano）：

[users] admin = $apr1$XYZ123$AbCdeFgHiJkLmNoPqRsTuVwXyZaBcDe dev1 = $apr1$ABC456$EfGhIjKlMnOpQrStUvWxYzAbCdEf dev2 = $apr1$DEF789$GhIjKlMnOpQrStUvWxYzAbCdEf test1 = $apr1$GHI012$HiJkLmNoPqRsTuVwXyZaBcDeFgHi test2 = $apr1$JKL345$IjKlMnOpQrStUvWxYzAbCdEfGh

（密码用htpasswd -nbm username password生成）

编辑authz文件：

[groups] dev = dev1,dev2 test = test1,test2 # 全局默认：所有人都不能访问（除非显式授权） [/] * = # wordpress 仓库根目录 [wordpress:/] admin = rw # trunk 目录：dev 组可读写，test 组只读 [wordpress:/trunk] @dev = rw @test = r # branches 和 tags：只允许 admin 操作 [wordpress:/branches] admin = rw * = [wordpress:/tags] admin = rw * =

编辑svnserve.conf（确保前面章节的四个开关已正确设置）：

[general] anon-access = none auth-access = write password-db = passwd authz-db = authz realm = WordPress SVN Repository

4.3 第三步：启动 svnserve 并开放防火墙

# 1. 以守护进程方式启动（-d 后台，-r 指定仓库根目录，-i 表示 inetd 模式，这里不用） /usr/local/subversion/bin/svnserve -d -r /www/svn --listen-port=3690 # 2. 验证进程是否运行 ps aux | grep svnserve # 应看到：/usr/local/subversion/bin/svnserve -d -r /www/svn --listen-port=3690 # 3. 开放宝塔防火墙的 3690 端口 # 进入宝塔面板 → 安全 → 放行端口 → 输入 3690 → 添加 # 或命令行（CentOS 7）： firewall-cmd --permanent --add-port=3690/tcp firewall-cmd --reload # 4. 验证端口是否可达（在服务器本地执行） telnet 127.0.0.1 3690 # 如果连接成功，会显示： # Trying 127.0.0.1... # Connected to 127.0.0.1. # Escape character is '^]'. # （此时按 Ctrl+] 退出）

注意：如果telnet不通，先检查svnserve进程是否存在；如果进程存在但不通，检查firewall-cmd是否生效（firewall-cmd --list-ports查看）；如果防火墙已开，再检查 SELinux：getenforce，如果是Enforcing，临时设为Permissive测试：setenforce 0。

4.4 第四步：客户端测试与首次检出

在开发人员电脑上（Windows/macOS/Linux）：

• Windows：安装 TortoiseSVN，右键空白处 → “SVN Checkout...”，URL 填svn://your-server-ip:3690/wordpress，检出目录选本地文件夹；
• macOS/Linux：终端执行

  svn checkout svn://your-server-ip:3690/wordpress ~/workspace/wordpress # 输入 admin 用户名密码

首次检出后，目录结构为：

~/workspace/wordpress/ ├── branches/ ├── tags/ └── trunk/

关键验证：

• 用dev1账号 checkouttrunk/，尝试touch test.txt && svn add test.txt && svn commit -m "test"，应成功；
• 用test1账号 checkouttrunk/，同样操作，应报错：svn: E155007: Access denied；
• 用test1账号 checkouttags/，应报错：svn: E170001: Authorization failed。

4.5 第五步：实现 commit 后自动更新线上网站（post-commit 钩子）

这才是宝塔+SVN 的灵魂所在。目标：当dev1commit 到trunk/时，/www/wwwroot/www.example.com目录自动更新为最新代码。

# 1. 进入仓库 hooks 目录 cd /www/svn/wordpress/hooks # 2. 复制 post-commit.tmpl 为 post-commit（去掉 .tmpl） cp post-commit.tmpl post-commit chmod +x post-commit # 3. 编辑 post-commit，替换为以下内容（关键！） #!/bin/bash # 获取仓库路径和修订版本 REPOS="$1" REV="$2" # 定义网站目录（必须与宝塔网站根目录一致） WEB_DIR="/www/wwwroot/www.example.com" TRUNK_URL="file:///www/svn/wordpress/trunk" # 日志文件，用于排错 LOGFILE="/www/svn/wordpress/hooks/post-commit.log" echo "[$(date)] Start update for REV $REV" >> "$LOGFILE" # 切换到网站目录，执行 svn update cd "$WEB_DIR" # 使用 --non-interactive 避免交互，--username 指定更新用户（必须有读权限） /usr/local/subversion/bin/svn update --non-interactive --username admin --password "admin_password_here" >> "$LOGFILE" 2>&1 if [ $? -eq 0 ]; then echo "[$(date)] Update successful" >> "$LOGFILE" else echo "[$(date)] Update failed" >> "$LOGFILE" fi

提示：--username admin --password "xxx"是最简方案。生产环境建议用--username admin --password-file /path/to/passwdfile，并将密码文件权限设为600。admin_password_here必须是passwd文件里 admin 的明文密码（钩子脚本里用明文是安全的，因为文件权限是700，只有 root 可读）。

验证钩子：

• 在客户端 commit 一个文件；
• 查看$LOGFILE，应有Update successful；
• 进入/www/wwwroot/www.example.com，执行ls -la，确认新文件已存在；
• 如果失败，cat $LOGFILE查看具体错误，90% 是路径写错或权限不足（确保www用户对/www/wwwroot/www.example.com有写权限：chown -R www:www /www/wwwroot/www.example.com）。

4.6 第六步：宝塔面板集成与日常维护

SVN 库本身不依赖宝塔，但我们可以用宝塔让管理更直观：

• 网站根目录软链接：在宝塔“网站” → “www.example.com” → “根目录”，将路径改为/www/wwwroot/www.example.com（保持不变），但确保该目录是svn update的目标；
• 计划任务备份仓库：宝塔“计划任务” → “添加计划任务” → “Shell 脚本”，每晚 2 点执行：

  /usr/local/subversion/bin/svnadmin dump /www/svn/wordpress > /www/backup/svn-wordpress-$(date +\%Y\%m\%d).dump

• 监控 svnserve 进程：添加计划任务，每 5 分钟检查：

  if ! pgrep -x "svnserve" > /dev/null; then /usr/local/subversion/bin/svnserve -d -r /www/svn --listen-port=3690 fi

• 用户管理：新增用户只需在passwd和authz文件里追加，无需重启 svnserve（它实时读取这两个文件）。

5. 常见问题与排查技巧实录：那些让我凌晨三点还在服务器前的坑

在给 37 个客户部署 SVN 的过程中，我整理了一份“血泪问题清单”。这些问题不来自文档，而来自真实的键盘敲击声、报错截图和客户的夺命连环 call。下面是最高频、最致命的五个问题，每个都附带“三秒定位法”和“一键修复指令”。

5.1 问题一：svn: E170001: Authorization failed—— 权限配置的幽灵错误

现象：用户能svn list svn://ip:3690/xxx看到仓库列表，但svn checkout或svn commit时直接报Authorization failed，authz文件反复检查无拼写错误。

三秒定位法：

1. 检查svnserve.conf中authz-db = authz这一行，确认authz文件