银河麒麟源码编译Subversion 1.8.14与svnserve部署排障

简介：这份资源面向在银河麒麟（国产 Linux）系统上需要搭建版本控制服务的管理员与开发人员，围绕「从源码编译安装 SVN 环境」这一实际问题，给出一条可落地的完整安装路线。包中共 1 个 docx 文档，约 202KB，以文字步骤与命令片段为主，体积小、查阅方便，适合作为部署时的对照手册。内容覆盖预编译依赖 apr、apr-util 与 sqlite 的下载与 configure/make 安装，Subversion 源码编译，/etc/profile 环境变量配置与 svnserve 版本验证，以及版本库目录创建、svnadmin create 建库等环节，并说明 svnserve.conf、passwd、authz 三个配置文件的关键项写法，包括匿名访问关闭、鉴权用户读写、用户口令与群组权限设置，还涉及服务启动与开机自启脚本、Windows 客户端访问地址格式等延伸细节。已有 2798 人学习，适合需要在内网或离线环境自建 SVN 服务、希望减少编译与配置踩坑的读者参考。

1. 银河麒麟上装 SVN：系统源自带的版本为什么常常不能直接用

一台银河麒麟服务器要接回一套跑了很多年的版本管理流程，运维给过来的要求很朴素：地址不变、账号不变、hook 脚本别动。真正动手才发现，系统源里的 subversion 版本和这套流程对不上，svnadmin dump出来的东西在两边行为不一致，钩子脚本里的路径假设也不一样。老项目维护最怕版本漂移，所以我一般不从源里装，而是把 subversion 1.8.14 连同 apr、apr-util、sqlite 一起源码编译，锁死在/usr/local/svn这个前缀下。

这条路适合两类人：一是在国产化平台上必须把 svnserve 跑起来、又拿不到合适软件包的运维；二是需要固定版本、机器在内网、只能靠 U 盘或跳板机往里传包的开发。整个过程不难，难的是依赖顺序、动态库路径和那三个配置文件里的细节，下面按我实际走通的顺序拆。

2. 依赖三件套：apr、apr-util、sqlite 的编译顺序与参数怎么定

subversion 不是一个能单独站住的程序。它把文件操作、内存池、字符串处理、网络收发几乎全部压在 Apache Portable Runtime 上，所以 apr 和 apr-util 必须先就位；而 1.8 这一支又把 sqlite 的源码直接塞进自己的构建流程里，用一份 amalgamation 源码现场编，不依赖系统里的 libsqlite3。三者的关系是一条链，顺序错了 configure 就会在探测阶段直接退出。

2.1 为什么必须先 apr 后 apr-util，再轮到 subversion

apr-util 的 configure 脚本第一件事就是找 apr 的头文件和库，找不到就报错退出。而 subversion 的 configure 会同时找 apr 和 apr-util，两个都齐了才继续往下探测。所以顺序只能是 apr → apr-util → subversion，没有别的排列。

这里还有个容易被忽略的点：apr 和 apr-util 的版本要成套。apr-1.6.5 配 apr-util-1.6.1 是同一代的组合，跨代混搭时 configure 未必报错，但编译到一半出现结构体成员不匹配的情况我见过不止一次。手上没有成套的包，就先停下来把版本对齐，别硬编。

安装前缀我习惯分开写：/usr/local/apr、/usr/local/apr-util、/usr/local/svn。全都塞进/usr/local看着省事，实际是给自己埋雷——头文件和库全糊在一起，将来想单独升级或卸掉其中一个，根本分不清哪些文件是谁的。

# 全程 root，源码包统一放在 /home/dmdba/svn 下 cd /home/dmdba/svn # 1) 编译 apr，只依赖系统自带的 gcc / make cd apr-1.6.5 ./configure --prefix=/usr/local/apr make -j4 make install # 2) 编译 apr-util，--with-apr 指向 apr 的安装前缀，不是源码目录 cd ../apr-util-1.6.1 ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr make -j4 make install

--prefix决定make install把东西放到哪，后面 subversion 的--with-apr必须和它一字不差。-j4是按 CPU 核数给的，编译机上核多可以给到 8，核少就给 2，给太高在内存紧张的虚机上会因为 OOM 直接杀掉编译进程，表现成莫名其妙的make: *** [xxx] Killed。

2.2 apr-util 的--with-apr写错会怎么表现

--with-apr后面跟的必须是 apr 的安装前缀（/usr/local/apr），不是解压出来的源码目录（/home/dmdba/svn/apr-1.6.5）。写成源码目录时 configure 有时也能过，因为它能在源码树里找到apr.h，但make install之后 apr-util 里记录的路径是错的，等到 subversion 链接阶段才会以cannot find -lapr-1的形式爆出来。

判断方法很直接，configure 跑完看它打印的摘要行：

./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr 2>&1 | tail -20

正常的输出里会出现checking for apr-config... /usr/local/apr/bin/apr-1-config这样的行。如果这一行显示的是源码目录，或者干脆是no，就说明路径给错了，别急着 make，先回去改。

另外，如果系统里缺 expat 开发包，apr-util 会跳过 expat 支持继续编。这对 svnserve 本身影响不大，但如果后面要接 Apache httpd 做 http 访问就会缺 DAV 相关能力。想一次到位，编译前把expat-devel、zlib-devel、openssl-devel装上，能省掉后面重编 apr-util 的返工。

2.3 sqlite-amalgamation 不用编译，但改名和位置是硬约束

subversion 1.8.14 的构建脚本不调用系统的 sqlite3，而是在源码根目录下找sqlite-amalgamation/sqlite3.c这个文件，找到之后现场编进去。这个约定非常死，目录名差一个字符都不认。

从官网下下来的是sqlite-amalgamation-3071501.zip，解压出来是同名目录。必须把它挪到 subversion 源码根目录下，并且改名为sqlite-amalgamation：

cd /home/dmdba/svn unzip sqlite-amalgamation-3071501.zip # 挪进 subversion 源码树，并改成构建脚本认的名字 mv sqlite-amalgamation-3071501 subversion-1.8.14/sqlite-amalgamation # 确认文件在位，这一步别省 ls -l subversion-1.8.14/sqlite-amalgamation/sqlite3.c

最后那条ls是我每次都会敲的。少敲这一下，等到 subversion 编了十几分钟才报sqlite3.c: No such file，返工的时间远比这一行命令贵。

2.4 离线传包与解压后的目录规划

内网机器最常见的传包方式是跳板机 scp 或 U 盘挂载。不管哪种，落地之后统一解压到同一个父目录，路径才好写：

cd /home/dmdba/svn tar -zxvf apr-1.6.5.tar.gz tar -zxvf apr-util-1.6.1.tar.gz tar -zxvf subversion-1.8.14.tar.gz unzip sqlite-amalgamation-3071501.zip ls -d apr-1.6.5 apr-util-1.6.1 subversion-1.8.14 sqlite-amalgamation-3071501

四个包解压后应该平级出现在/home/dmdba/svn下，这是后面所有cd命令的前提。传包过程中最怕的是压缩包被截断，tar -zxvf报unexpected EOF就是这个原因，重传一遍即可，别怀疑包本身。

提示：银河麒麟的默认 shell 和 coreutils 与新版本发行版存在差异，脚本里凡是涉及通配符和路径拼接的地方，宁可写全路径，也别依赖相对路径的推断。

3. subversion 1.8.14 编译：configure 三个--with与 make 中断的处理

依赖齐了之后，subversion 这一关卡人的地方集中在两个阶段：configure 的依赖探测，和 make 的链接阶段。前者报错很干脆，一行红字告诉你缺什么；后者往往要滚几百行才露出真正的原因，得会从日志尾部往回翻。

3.1 configure 阶段依赖探测的三个关键参数

subversion 的 configure 参数不少，真正必须显式给的就三个：安装前缀、apr 路径、apr-util 路径。

cd /home/dmdba/svn/subversion-1.8.14 ./configure \ --prefix=/usr/local/svn \ --with-apr=/usr/local/apr \ --with-apr-util=/usr/local/apr-util \ 2>&1 | tee /tmp/svn-configure.log

三个参数的含义务必分清：--prefix是自己要装到哪，--with-apr和--with-apr-util是依赖在哪。前一个写错，装完找不到命令；后两个写错，configure 直接报APR not found或APR-UTIL not found然后退出。

tee那一段不是多余的。configure 输出动辄几百行，滚屏之后想回头找具体是哪个探测失败，只能靠日志。养成把 configure 和 make 的输出都落一份到/tmp的习惯，出问题时grep -i error一下就能定位。

configure 顺利跑完时，末尾会打印一段摘要，里面能看到APR、APR-UTIL、SQLite各自的版本和路径。这一段建议截图或复制留存，将来排查版本不一致时是唯一的对照依据。

3.2 make 中断先看这三处，不要急着重装系统

make 失败的原因五花八门，但在麒麟上装 1.8.14 这个组合，九成跑不出下面三种：

第一处，sqlite3.c 找不到。前面 2.3 节说过，目录名和位置不对就会在编译到 sqlite 那一层时中断。解决办法是把sqlite-amalgamation目录放回 subversion 源码根目录并确认文件名。

第二处，链接阶段报undefined reference to一串 apr 符号。这基本是 apr-util 编译时没真正链上 apr，回头重编 apr-util，--with-apr指向安装前缀，别指向源码目录。

第三处，编译器把警告当错误。新版 gcc 对某些老代码的隐式类型转换会给出-Werror级别的提示，1.8.14 这样的老代码在新工具链上偶尔会撞上。这种情况不是代码坏了，是编译选项太严，可以在 configure 时加一句放宽：

# 编译失败时，先把完整日志留下来，再决定怎么改 make -j4 2>&1 | tee /tmp/svn-make.log # 从日志尾部往前找第一个 error，而不是从头读 grep -n -i "error" /tmp/svn-make.log | head -20

grep出来的第一条 error 往往不是根因，真正的根因通常在它上面几十行。用sed -n '起始行,结束行p' /tmp/svn-make.log把上下文打出来看，比一行行往上翻快得多。

3.3 动态库路径：/etc/ld.so.conf.d里那两行省不得

make install成功不代表能跑。subversion 的可执行文件链接的是/usr/local/svn/lib下的libsvn_*，apr 的库在/usr/local/apr/lib，这些目录都不在系统默认的库搜索路径里。不处理的话，svnserve --version会以error while loading shared libraries: libsvn_client-1.so.0收场。

正确做法是交给 ldconfig 管理，而不是在/etc/profile里堆LD_LIBRARY_PATH：

cat > /etc/ld.so.conf.d/svn.conf <<'EOF' /usr/local/apr/lib /usr/local/apr-util/lib /usr/local/svn/lib EOF # 让新配置生效 ldconfig # 验证库是否已被系统识别 ldconfig -p | grep -E "libsvn_client|libapr-1"

三行路径按依赖顺序排列，ldconfig会把它们加进缓存。用 conf.d 的好处是干净、可回滚，将来升级只需改这一个文件再ldconfig。相比之下，往/etc/profile里追加LD_LIBRARY_PATH只对交互式登录的 shell 生效，systemd 拉起的服务和 cron 任务读不到，是典型的“手动能跑、开机就挂”。

3.4 PATH 生效与svnserve --version的冒烟验证

最后一步是把/usr/local/svn/bin加进 PATH。写在/etc/profile末尾，对所有用户生效：

cat >> /etc/profile <<'EOF' # Subversion export PATH=$PATH:/usr/local/svn/bin EOF # 当前会话立即生效 source /etc/profile # 三件事一起验：命令找得到、版本对得上、动态库加载正常 which svnserve svnserve --version svn --version --quiet

which svnserve应该输出/usr/local/svn/bin/svnserve。如果输出的是/usr/bin/svnserve，说明系统里原本就装着 subversion，PATH 顺序不对，把/usr/local/svn/bin提到前面，或者干脆把系统自带的卸掉，避免两套混用。

svnserve --version会打印版本号和编译时间，同时把依赖的 apr、apr-util、sqlite 版本一并列出来。这一屏信息极其有用，后面遇到任何行为异常，第一件事就是回来核对这三个版本号。

注意：svn --version --quiet只输出版本号，适合写进脚本做版本断言；svnserve --version输出更全，适合人工核对。

4. 版本库与权限：svnadmin create之后的三个配置文件怎么落地

服务能启动只是开始，真正决定这套 SVN 好不好用的是版本库结构和权限模型。svnadmin create一条命令就能建库，但它生成的conf目录里那三个文件，任何一个改错都会让客户端连不上，而且报错信息相当不友好。

4.1svnadmin create的实际产物与目录规划

版本库根目录的选择有讲究。放在/home/svn下方便备份，但要注意系统安全策略对这个路径的读取限制；放在/var/svn下更符合常规，权限管理也更顺。我这边沿用/home/svn，因为备份脚本早就按这个路径写死了。

# 版本库的父目录，注意这一步只是普通目录 mkdir -p /home/svn # 项目目录，作为单个版本库存在 mkdir -p /home/svn/project # 关键一步：把普通目录变成 SVN 版本库 svnadmin create /home/svn/project # 看它生成了什么 ls -l /home/svn/project

执行完svnadmin create之后，/home/svn/project下会多出conf、db、hooks、locks、format、README.txt。db是 FSFS 格式的实际存储，日常不用碰；hooks放提交前后的钩子脚本，老流程里那些“提交后发邮件”的逻辑就挂在这；conf是接下来要改的三个文件所在。

有一点要提前说清楚：/home/svn是所有版本库的父目录，/home/svn/project才是一个版本库。这个层级关系决定了后面svnserve -r参数该指到哪，搞混了客户端就会连到空路径。

4.2svnserve.conf：四行配置的作用域和顶格规则

conf/svnserve.conf是服务端的总开关，里面的配置项全部要顶格写，行首不能留空格，注释行用#开头。这不是格式洁癖，解析器对前导空白极敏感，行首多一个空格就会导致启动失败，而且报错信息只说“配置错误”，不告诉你是哪一行。

[general] anon-access = none auth-access = write password-db = passwd authz-db = authz realm = /home/svn

五行的含义逐条过一遍：

• anon-access = none：匿名用户什么都不能做。默认是read，意味着不登录也能看代码，这个默认值在公网环境是重大风险，必须改。
• auth-access = write：通过认证的用户可以读写。只想给某些人读权限，靠下面的 authz 文件控制，这一行给write是上限。
• password-db = passwd：账号密码文件。这里写的是相对路径，相对于conf目录，所以实际读的是conf/passwd。
• authz-db = authz：权限控制文件，同样是相对conf的路径。
• realm = /home/svn：认证域。这一行原配置里没有，建议加上。不设的话客户端会用默认域缓存凭据，同一台机器连多个不同 SVN 服务时，账号密码会互相覆盖，表现成“密码明明对却一直认证失败”。

password-db和authz-db也可以写绝对路径。写绝对路径的好处是不受conf目录位置影响，坏处是迁移版本库时要跟着改。我一般保持相对路径，把整个版本库目录一起搬走就能用。

4.3passwd与authz：分组、路径前缀与匹配顺序

passwd只管账号，不管权限，格式极简：

[users] admin = 123456 dev01 = 123456 dev02 = 123456

等号两边可以有空格，解析器会裁掉。密码是明文存储，这一点要有心理准备——conf目录的权限必须收紧到700，否则同机器上任何用户都能看到密码。

authz才是真正决定谁能访问哪里的地方，它支持分组、路径和权限三元组：

[groups] g_admin = admin g_dev = dev01,dev02 [/] @g_admin = rw @g_dev = r * =

逐段解释：

• [groups]段定义组。一个用户可以属于多个组，组名前面加@引用。
• [/]表示版本库根路径。注意这个斜杠是相对版本库根，不是文件系统根。如果只想放开某个子目录，写成[/trunk/docs]这种形式。
• @g_admin = rw：管理员组读写。
• @g_dev = r：开发组只读。
• * =：除上面列出的组之外的所有用户，权限为空，也就是拒绝。这一行必须写，不写的话未列出的用户会落到默认策略，容易出现“谁都能进”的意外。

匹配顺序是从具体到宽泛：路径越长的规则优先，同一条路径上用户规则的优先级高于组规则。所以给某个特定用户单独开权限时，直接把用户名写进去，比如zhangsan = rw，它会覆盖所在组的限制。

改完这三个文件不需要重启服务，svnserve 每次请求都会重新读配置。这一点很省事，但也意味着改错了会立刻生效，改之前先备份一份。

4.4svnserve -d -r的-r到底停在哪一层

启动命令是svnserve -d -r /home/svn。-d是守护进程模式，-r是版本库根路径。关键在于-r要指到所有版本库的父目录，不是某个具体版本库：

# 正确：指到父目录 /home/svn svnserve -d -r /home/svn # 错误：指到具体版本库，客户端 URL 会多一层，且其他库访问不到 # svnserve -d -r /home/svn/project # 确认进程和端口 ps -ef | grep svnserve ss -lntp | grep 3690

-r /home/svn之后，客户端访问地址是svn://服务器IP/project。如果写成-r /home/svn/project，地址就变成svn://服务器IP/，而且再想加第二个项目就得重启服务换路径。

端口默认 3690，启动后必须确认防火墙放行：

# firewalld 环境 firewall-cmd --permanent --add-port=3690/tcp firewall-cmd --reload firewall-cmd --list-ports

ps能看到进程但客户端连不上，八成就是防火墙这一层。这个坑后面还会细说。

5. 避坑与排查：五条在麒麟上真踩过的记录

下面的每一条都是实际遇到的，按“现象 → 原因 → 解决”的顺序写，遇到同类问题时可以直接对号入座。

5.1 启动即退出，日志里只有一行 “Option expected”

现象：执行svnserve -d -r /home/svn后进程没起来，前台跑一次就输出svnserve: /home/svn/project/conf/svnserve.conf:12: Option expected然后退出。

原因：svnserve.conf里某个配置项前面留了空格或制表符。这个文件是 ini 风格解析，但解析器对行首空白零容忍。常见的触发场景是从网页或聊天窗口复制配置，粘贴时带了缩进。

解决：用cat -A conf/svnserve.conf把所有不可见字符打出来，行首出现^I（制表符）或一串空格的就是元凶。把所有配置项改成顶格，注释行统一用#开头，改完再启动。养成习惯：改完这个文件先cat -A扫一眼，再敲启动命令。

5.2 客户端 Connection refused，服务端ps却能看到进程

现象：服务器上ps -ef | grep svnserve有进程，端口也在监听，但 Windows 客户端连svn://192.168.10.20/project报Unable to connect to a repository at URL，底层是连接被拒。

原因：系统防火墙没放行 3690。另一种情况是svnserve监听在 IPv6 而客户端走 IPv4，ss -lntp的输出里如果只有[::]:3690而没有0.0.0.0:3690，就是这个原因。

解决：先放行端口，firewall-cmd --permanent --add-port=3690/tcp && firewall-cmd --reload；再确认监听地址，ss -lntp | grep 3690应能看到0.0.0.0:3690。如果只监听 IPv6，检查/etc/hosts和系统是否禁用了 IPv4 回环。

5.3 密码没错却一直认证失败

现象：客户端反复弹认证框，输入admin/123456始终提示认证失败，服务端日志里没有明显报错。

原因：最常见的是passwd文件里的用户名带了前后空格，或者authz里根本没有为这个用户配置任何路径权限。还有一种隐蔽情况是客户端缓存了旧凭据，清掉缓存前怎么输都不对。

解决：先用svn auth --show-passwords或客户端自带的“清除认证缓存”把本地缓存清掉；再核对authz里是否有[/]段对这个用户或所在组授权；最后检查passwd文件的编码，必须是 UTF-8 无 BOM，带 BOM 时第一行用户名会解析失败。

5.4 重启后 SVN 没起来，rc.local里的脚本像没执行

现象：手动执行/root/svn.sh一切正常，重启机器后ps里没有 svnserve 进程，脚本里的日志也没写。

原因：/etc/rc.d/rc.local这个文件在新版系统上默认没有执行权限，systemd 不会去跑它。另一个原因是脚本里写的是相对路径svnserve，而开机时 PATH 还没加载到/usr/local/svn/bin。

解决：chmod +x /etc/rc.d/rc.local给上执行权限；脚本里改用绝对路径/usr/local/svn/bin/svnserve -d -r /home/svn。查绝对路径用which svnserve。更稳妥的做法是舍弃 rc.local，写成 systemd 服务单元，下一章展开。

5.5svn命令能跑，svnserve却说找不到 libsvn_client

现象：交互式登录后svn --version正常，但svnserve启动报error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file。

原因：动态库搜索路径没配。svn和svnserve链接的库不完全相同，前者可能命中了系统自带的旧库，后者走的是/usr/local/svn/lib。

解决：按 3.3 节写/etc/ld.so.conf.d/svn.conf，把三个 lib 目录列进去，执行ldconfig，再用ldconfig -p | grep libsvn确认。改完必须重开一个会话，旧会话的环境变量还是老的。

6. 把 svnserve 交给 systemd：一次写对，之后不用再碰 rc.local

rc.local那套做法在老系统上能用，但在麒麟这一类新系统上，它依赖“被手动赋予执行权限”这个前提，换台机器部署就得重新记得敲一次chmod +x，属于典型的靠人肉记忆维持的配置。我现在的做法是直接写 systemd 单元，一次写对，后面复制过去就能用。

先看单元文件。放在/etc/systemd/system/svnserve.service：

[Unit] Description=Subversion Server After=network.target [Service] Type=forking ExecStart=/usr/local/svn/bin/svnserve -d -r /home/svn ExecStop=/usr/bin/pkill -f "svnserve -d -r /home/svn" Restart=on-failure RestartSec=3 [Install] WantedBy=multi-user.target

几个关键点说明一下。Type=forking是因为svnserve -d会自己 fork 到后台，父进程立刻退出，systemd 需要知道这一点才不会误判服务已死。ExecStart里用的是绝对路径，绕开 PATH 未加载的问题。ExecStop用pkill -f按完整命令行匹配，比按进程名杀更精确，避免误伤其他 svn 相关进程。Restart=on-failure加RestartSec=3是给自己留的后悔药——进程意外退出时 3 秒后自动拉起，比人肉发现再登录处理快得多。

启用和验证按这个顺序走：

# 重新加载单元文件，让新写的 service 生效 systemctl daemon-reload # 设为开机自启并立即启动 systemctl enable --now svnserve # 看状态，重点看 Active 那一行是不是 active (running) systemctl status svnserve --no-pager # 从外部验证端口真的在监听 ss -lntp | grep 3690

systemctl status的输出里如果出现Active: active (running)，说明服务起来了；如果是failed，用journalctl -u svnserve -n 50 --no-pager看最近 50 行日志，比翻/var/log/messages快得多。

服务起来之后，验证要分三层做，别只做最上面一层：

三层里最容易漏的是第二层。很多人直接拿 Windows 客户端试，连不上时分不清是服务端问题还是网络问题。先在服务器本机用svn info打一次，本机通了再排查网络，问题范围立刻缩小一半。

最后说个我自己的习惯。每次交付这类环境，我都会把svnserve.conf、passwd、authz三个文件连同 systemd 单元一起打包到版本库的docs/目录下，写清楚版本号和改动日期。不是怕自己忘，是怕半年后接手的人对着一个跑着的服务完全不知道它当初是怎么配起来的——这台机器会变成一个黑匣子。从那以后我每次装完 SVN，都会强制走一遍“本机 svn info → 外部 checkout → 重启机器再验一次”这三步，缺一步都不算交付完成。希望帮到你。

本文还有配套的精品资源，点击获取