简介：面向银河麒麟等国产操作系统环境下的运维与开发人员，这份实战指南系统整理了SVN服务器的完整搭建流程。文档从编译安装前置组件入手，逐一给出apr、apr-util、SQLite与Subversion的源码下载、configure参数和make安装命令，并说明了环境变量添加与生效方法，可帮助读者避开常见的依赖与路径踩坑问题。包体为一个docx文档，大小约202KB，适合对照步骤边做边查；已有2788人浏览学习。文档内容覆盖版本库创建、svnserve.conf/passwd/authz三个文件的权限配置、svnserve启动方式及开机自启脚本设置，同时给出了客户端访问地址格式与常见配置错误提示，例如svnserve.conf首行不能留空、用户名口令与权限分组写法等。整个文档按操作顺序分步书写，重点标注了命令行与常用参数，无论是初次接触编译安装，还是需要为项目快速搭建SVN服务，这份笔记都能提供完整参考，有效减少试错时间。
1. 银河麒麟装SVN：从一次代码资产迁移说起
某项目X在旧服务器上跑了三年的SVN仓库要整体迁到银河麒麟机器上。原以为yum install一把梭，结果默认软件源里压根没这个包，找到离线rpm又缺依赖，好不容易装上，svnserve.conf改了却一直不生效，查了半天发现是行首多了个空格。这个标题要解决的，就是这类“看着简单、做起来处处别扭”的部署工作：在银河麒麟上把SVN客户端和服务端真正跑起来，让团队能正常提交、能按权限拉取、断电重启后服务还能自动拉起。适合三类人：要接管代码仓库的运维、需要本地提交历史的开发者、做旧仓库迁移的负责人。如果你正对着麒麟终端发呆，不知道从哪敲第一行命令，这篇文章就是你需要的路线图。
2. 装SVN前先回答两个问题：系统是什么形态，源里有什么
2.1 先看系统和软件源：yum还是apt，源里有没有subversion
我拿到一台银河麒麟，第一件事不是装包，而是确认系统的口味。银河麒麟桌面版和服务器版的包管理器不一样，有的镜像默认走yum，有的走apt，直接敲错命令会得到一堆误导报错。
cat /etc/os-release uname -r && uname -m if command -v yum >/dev/null; then echo "yum manager"; fi if command -v apt >/dev/null; then echo "apt manager"; fi yum search subversion 2>/dev/null这段脚本的作用是：先看发行版标识和版本号，再确认内核和架构（x86_64还是aarch64，这决定你后面找的安装包平台），最后探测可用的包管理器并直接搜索subversion。如果yum search有结果，说明默认源里有包，直接进入第3章；如果没结果，就要考虑挂载系统安装光盘作为本地源或用离线rpm包。常见做法是优先把默认软件源修通，而不是一上来就去下载第三方包，因为subversion依赖apr、apr-util、sqlite等一串库，手工装rpm很容易陷入缺一个补一个的死循环。
如果你和我一样不太想跟依赖较劲，就把系统ISO挂载成本地仓库：
sudo mount /dev/cdrom /mnt sudo sh -c 'echo "[local] name=local baseurl=file:///mnt/Packages enabled=1 gpgcheck=0" > /etc/yum.repos.d/local.repo' sudo yum clean all && yum makecache说明一下最后两行的参数：baseurl指向光盘里的Packages目录，gpgcheck=0是跳过签名校验，因为这是内网挂载的介质，风险可控；如果你们的镜像源放在HTTP服务器上，把baseurl换成http地址就行。装完之后确认yum makecache有没有真正拉到索引，没拉到就去看/etc/yum.repos.d/local.repo的路径是不是多写了一层Packages，这个路径写错非常常见。
2.2 先想清楚：你只要客户端，还是连服务端一起搭
很多人搜这个关键词是冲着“能checkout代码”来的，这其实只需要客户端；如果把仓库也放在这台机器上，才需要服务端。这两个场景的安装策略完全不同，缺省装法虽然都能用，但你会多维护一堆用不上的东西。我自己一般先按这个表判断：
| 使用场景 | 需要装的组件 | 对应命令 |
|---|---|---|
| 连接到已有SVN服务器，日常提交代码 | 客户端 | svn |
| 服务器上新建仓库，供多人访问 | 服务端 | svnserve |
| 浏览器里看代码、走HTTP协议 | 服务端加Apache模块 | httpd + mod_dav_svn |
在银河麒麟上，subversion这个包会同时带来svn和svnserve两个命令，所以装一个包两端都齐了。真正的差别在服务端多了仓库初始化、配置文件和守护进程三块任务。另外注意，麒麟系统上有时候bin目录里看不到svnserve，别急着以为装坏了，先运行/usr/bin/svnserve --version确认，之后再排查PATH环境变量，很多时候只是用户环境变量没更新而已。
3. 在银河麒麟上装好SVN客户端：最小命令与图形界面选择
3.1 最小安装命令与第一次checkout
如果默认软件源里有subversion，客户端的最小安装就这么两行：
sudo yum install -y subversion svn --version第一行会把svn、svnserve以及依赖的apr库一起装好；第二行用来确认安装路径和库版本，输出里能看到svn版本、编译的SSL支持以及已启用的认证方式。有些机器上默认没改PATH，/usr/bin/svn可能不在用户环境变量里，先which svn看一眼，找不到就用/usr/bin/svn --version，这种情况多见于从源码编译安装的用户。
安装完到用起来还差一次真实连接验证。拿一台服务器地址是192.0.2.10、仓库名proj-demo举例：
mkdir -p ~/work && cd ~/work svn co svn://192.0.2.10/proj-demosvn co后面跟的URL格式是svn://主机名或IP/仓库名，端口默认3690。命令成功后会提示版本号和checkout的目录。如果提示无法解析主机名，把主机名改成IP再试；提示连接被拒绝则多半是服务端没起或防火墙问题，这个放到第5章讲。我建议第一次验证别用空仓库，最好在服务端先建一个带目录结构的仓库，checkout后能看到目录层级才算真正通了。这一步值得专门做一次，线上很多“装好了”其实只是svn命令能敲出来，真去拉代码就翻车。
3.2 图形界面缺菜单怎么办：不同客户端工具的出路
银河麒麟的软件源里默认搜不到rapidsvn这类图形客户端是常态，不少同事装完命令行svn后，发现桌面右键菜单里没有任何SVN入口，就以为失败了。其实图形界面和命令行是两个独立的程序，菜单习惯由特定文件管理器插件提供，默认源没打包这个插件，装不上非常正常。
我的建议是分情况处理。日常就是改改配置文件、提交下脚本，用命令行svn就够，不需要图形界面，我用习惯了反而觉得命令行更快。新手或产品同学需要可视化对比版本，常见做法是装rapidsvn，如果yum search rapidsvn没结果，就自己编译安装，但这东西依赖wxWidgets，编译一顿几小时，我一般直接劝退。更省事的方案是用SVN命令行加diff工具，或者让浏览器走HTTP视图，前提是服务端搭了Apache。
这里还有一个高频翻车点：某些教程会叫你去修改桌面文件关联，让右键菜单里多出“SVN Update”之类的动作。银河麒麟桌面版的文件管理器框架跟常规Linux发行版不同，这个操作经常失效。别在菜单上花太多时间，命令行能用，业务就不卡。说到底，图形界面只是锦上添花，仓库能通、能提交、能回滚，才是真正要紧的事。
4. 银河麒麟上的SVN服务端：仓库初始化、配置与systemd托管
4.1 初始化仓库：目录规划、svnadmin create与属主调整
服务端的第一步不是启动进程，而是先决定仓库放哪。常见做法是建一个独立的系统用户svnuser，仓库统一放在/var/svn/repos下。这样svnserve进程不以root身份跑，被攻击或误操作时影响面能控制住。
sudo groupadd svn sudo useradd -r -g svn -d /var/svn -s /sbin/nologin svnuser sudo mkdir -p /var/svn/repos sudo svnadmin create /var/svn/repos/proj-demo sudo chown -R svnuser:svn /var/svn/repos/proj-demo sudo chmod 600 /var/svn/repos/proj-demo/conf/passwd这段脚本的要点在最后两行：chown把仓库属主从root改成svnuser，否则svnserve以svnuser身份启动后没有写权限；chmod是为下一节做准备，passwd文件里是明文账号密码，权限太松等于把口令发给所有能登录这台机器的人。如果以后要新增仓库，重复svnadmin create和chown两步就行。create之后先看一眼仓库结构，/var/svn/repos/proj-demo下会有conf、db、hooks、format这些目录。format文件里是仓库格式版本号，2表示FSFS较新的格式，如果是旧的BDB格式建议迁移，不过银河麒麟上svnadmin默认就是FSFS，一般不用操心这个。
4.2 配置svnserve.conf：四个参数决定访问模型
仓库的conf目录下有svnserve.conf、passwd、authz三个文件，svnserve.conf是总闸。下面是一份单人维护也能直接用的配置，重点是去掉了文件里的注释行：
[general] anon-access = none auth-access = write password-db = passwd authz-db = authz这四个参数的语义按表格记：
| 参数 | 可选值 | 说明 |
|---|---|---|
| anon-access | read / write / none | 匿名用户访问权限，公网仓库按需放read，内网一律none |
| auth-access | read / write / none | 认证用户权限，开发仓库填write |
| password-db | 文件名 | 指定账号密码文件，默认相对conf目录 |
| authz-db | 文件名 | 指定路径级授权文件，不配则所有登录用户对全部路径可写 |
passwd文件的格式非常简单，用户名后跟一个等号和口令：admin = 一个足够长的随机口令。个人的实验环境用明文口令问题不大；如果对安全要求高，SVN还支持SASL加密认证，但银河麒麟上要装cyrus-sasl相关包并改配置，小团队用不上，我一般不引入这个复杂度。
authz文件的作用是分目录收权，示例如下：
[groups] dev = user1,user2 [/] * = r @dev = rw[groups]定义用户组，[/]表示仓库根目录，是所有用户，@dev是组引用。这里最容易理解错的是= r这个规则，它表示未登录的匿名用户也能读，如果你在svnserve.conf里已经写了anon-access = none，这里再给读权限并不冲突，但为了内网数据安全，我习惯直接把那行删掉，只保留@dev = rw。改完配置文件之后，记得确认文件里没有Windows换行符和行首空格，否则SVN会静默忽略整行配置。
4.3 用systemd托管svnserve：开机自启与退出重拉
银河麒麟基于Linux体系，服务托管默认就是systemd。直接用svnserve -d启动属于临时方案，机器重启就没了，所以要写一个服务单元文件。用vim打开路径：
sudo vim /etc/systemd/system/svnserve.service内容如下：
[Unit] Description=Subversion server After=network.target [Service] Type=forking User=svnuser Group=svn ExecStart=/usr/bin/svnserve -d -r /var/svn/repos Restart=on-failure RestartSec=3 [Install] WantedBy=multi-user.target随后执行：
sudo systemctl daemon-reload sudo systemctl enable --now svnserve systemctl status svnserve单独说明几个关键字段：Type=forking表示svnserve启动后会把主进程转入后台，符合它的守护进程模式；-r /var/svn/repos是仓库根目录，这个参数决定了客户端URL里只能写到根以下的仓库名，写绝对路径反而会暴露系统目录结构；Restart=on-failure让进程非正常退出时自动拉起，配合RestartSec=3设置重启间隔。如果status卡在failed，先journalctl -u svnserve -n 50看日志，多半是仓库路径权限或配置文件语法问题，少部分情况是进程已存在端口被占。
5. 银河麒麟SVN踩坑指南：五类高频故障的排查与修复
5.1 svnserve.conf改了不生效：行首空格让整行被静默忽略
现象：配置文件里把anon-access改成了none，客户端依然能匿名读取。
原因：SVN的配置解析器对行首空白极其敏感，行首多一个空格，这一行就被当成无效配置跳过，解析器还不报错，悬得很。
解决：用cat -A svnserve.conf把行尾符号也显示出来，排查是否有^M（Windows换行符残留）和行首空格；有的话把格式统一。改完配置记得sudo systemctl restart svnserve，SVN不会热加载配置文件，不重启就是改了等于没改。这条是最容易让人挠头的，我第一次遇到时排查了半个下午。
5.2 启动报错缺依赖库：svnserve: error while loading shared libraries: libapr-1.so.0
现象：svnserve装好后一执行就报找不到共享库，客户端也连不上服务端。
原因：部分离线的rpm包安装时没有把apr、apr-util关联带上，SVN的运行依赖没有落地。多见于从旧系统拷贝二进制文件或手工解包rpm的场景。
解决：ldd /usr/bin/svnserve看一下缺的具体是哪个库，然后用yum install apr apr-util补齐。补齐后再ldd确认所有依赖都解析到了真实路径。最怕的是多个源混用导致链接到老版本库，检查/usr/lib和/usr/lib64下有没有多套库文件，有冲突时就要理清LD_LIBRARY_PATH指向哪个版本。装完之后从客户端再测一次握手，确认不是只把库文件凑齐了但链路没通。
5.3 提交时提示Can't get lock，仓库像卡死一样
现象：所有客户端执行commit都报“repository is locked”，但svnserve进程还活着，看仓库目录也没人手动操作。
原因：非正常断电或kill -9进程，导致仓库db目录里残留了未完成的事务锁文件。这也是SVN仓库用久之后的典型问题，越老的仓库越容易出现。
解决：先svnadmin lstxns /var/svn/repos/proj-demo列出未完成事务，确认全是旧事务后执行svnadmin recover /var/svn/repos/proj-demo让仓库自愈，再svnadmin verify走一遍完整性检查。恢复期间要暂停所有客户端提交请求，别一边recover一边有人写数据，不然等于边修边制造新问题。如果recover之后还有报错，把db目录下的锁文件手动清掉也可以，但前提是你确认没有活跃事务正在跑。
5.4 本机提交正常，其他机器连不上3690端口
现象：在服务器本机svn co能成功，别的机器一连接就报连接超时或拒绝。
原因：银河麒麟默认启用的firewalld把svnserve的3690/tcp挡在外面。本机能连是因为回环流量不走防火墙规则，所以这个坑非常隐蔽，服务端看起来一切正常，远端就是进不来。
解决：放行端口并重载规则：
sudo firewall-cmd --permanent --add-port=3690/tcp sudo firewall-cmd --reload端口放行后从客户端telnet 192.0.2.10 3690测一下，能通就往下走。别一上来就关selinux，这是惯常的粗暴做法，放行端口已经能解决绝大多数问题。如果端口放行后仍然超时，再去看云平台安全组或者机房防火墙有没有在下层拦截，这层最容易忽略。
5.5 迁移旧仓库后提交报错：权限拒绝但root能写
现象：用tar把整个仓库从旧机器拷到麒麟环境，svnserve启动正常，一提交就报Permission denied，但root手动写文件没问题。
原因：tar包保留了原机器uid，旧机器上仓库属主是uid 501，新环境svnuser的uid是别的值，进程访问仓库文件时权限校验失败。这个问题在从其他Linux发行版迁移过来时特别常见，因为各种发行版对系统用户的uid分配不一致。
解决：chown -R svnuser:svn /var/svn/repos/proj-demo重新归属，再用svnadmin verify验证完整性。顺便对比db目录和hooks目录的文件属主，这两个地方最容易残留不一致。迁移类的场景，我建议拷完仓库后第一件事就是find /var/svn -not -user svnuser -ls看一遍，把所有非属主文件全部一次性修正，不要等报错再处理。
6. 让SVN更顺手：钩子脚本和HTTP访问怎么取舍
6.1 用post-commit钩子做提交审计
SVN的hooks目录下放了仓库生命周期脚本，没启用的时候都是.tmpl后缀，复制一份去掉后缀就能用。最常见也值得先做的是post-commit，它会在每次提交完成后被调用。下面是一个把提交记录追加到审计日志的写法：
sudo vim /var/svn/repos/proj-demo/hooks/post-commit内容如下：
#!/bin/bash REPOS="$1" REV="$2" /usr/bin/svn log "$REPOS" -r "$REV" >> /var/log/svn/post-commit.log 2>&1脚本里的$1是仓库路径，$2是提交版本号；svn log把该版本的提交说明追加写入审计日志。写完之后记得chmod +x post-commit并确认属主是svnuser，脚本没有执行权限会被静默丢弃。做之前先在命令行手跑一遍，确认日志路径的父目录对svnuser有写权限，不然这个钩子就是个摆设。同理如果你想拦特定操作，pre-commit钩子可以在提交落库之前做校验，比如禁止提交某个临时文件类型，直接在脚本里加一段文件名匹配再exit 1就行。
6.2 什么时候上mod_dav_svn，什么时候继续用svnserve
服务端不只有svnserve一条路，还可以装在Apache里通过HTTP访问。这个选择不难做：如果团队里有人需要在浏览器里直接浏览代码历史，或者公司网络只放行80/443端口，那就值得上mod_dav_svn；如果只是小巧的命令行仓库，继续用svnserve反而省心。我不建议主力仓库直接上Apache方案，因为它把认证、权限、进程模型叠了三层，排查链路太长，银河麒麟的默认源里httpd相关模块也经常不全。但给小团队开一个只读的浏览器入口，依然是个不错的补充。
装好之后用http://服务器IP/svn/proj-demo访问，配置时注意避免在Location根路径下写Require all granted，宁可先拒绝后精确放行，让权限收得紧一点。
距离这个环境跑起来，其实只差一次真实的迁移演练。我自己的习惯是停服务、复制仓库、在新机器verify完整，再让一个同事从checkout开始走一遍验收流程。上次图快没做verify，隔两天就摸出一个被截断的版本文件，这种后悔药真的不想吃第二回，所以在交付之前把这一步做成固定动作。按第4、5章的步骤走完，希望帮到你。
本文还有配套的精品资源，点击获取
