简介：以银河麒麟操作系统为背景，完整讲解SVN环境安装的实操指南，面向需要部署版本控制服务的系统管理员和运维工程师。SVN在国产系统上的源码编译通常依赖Subversion、Apache Portable Runtime（apr）与SQLite等多个组件，组件间版本匹配和依赖关系复杂，需要依次下载、编译和配置，比常规Linux环境更易遇到兼容性问题。文档以docx格式整理，仅1个文件、约202KB，内容覆盖从apr和apr-util的编译安装，到Subversion和SQLite的源码编译，再到环境变量持久化与版本库创建的完整链路；重点说明了svnserve.conf、passwd、authz三个配置文件的具体编写方法，包括匿名访问控制、用户口令和目录读写权限，每一步均给出关键命令与示例注释。同时提醒了配置文件首行不能留空、修改profile后须执行source使生效等易错细节，并给出svnserve启动命令、开机自启脚本及Windows客户端访问地址格式，方便对照完成部署。资源现有2791人学习下载，适合具备一定Linux基础但希望高效搭建银河麒麟SVN环境的初中级运维人员，也可作为团队内部技术资料参考。
1. 银河麒麟装SVN为什么总在编译这一步翻车
很多人拿到银河麒麟服务器，第一件事就是装SVN做版本管理，结果发现直接yum install subversion要么源里没有，要么版本老得连svnadmin create都能报错。于是只能走源码编译这条路，而这条路最坑的不是Subversion本身，而是它依赖的APR和APR-Util。我当时在模拟项目X的服务器上装SVN，前前后后折腾了两个下午，最后发现把apr、apr-util、subversion三个源码包的编译顺序理顺，后面其实一气呵成。这篇笔记就按我实际操作的顺序来写，包含编译参数、版本库初始化、三个配置文件的设置，以及最后开机自启的处理。适合正在用银河麒麟或类CentOS系统、需要自己从源码搭建SVN服务的运维或开发人员。
2. 源码编译前的准备：版本搭配与目录规划
2.1 源码包选型：为什么我坚持用1.8.14而不是新版
Subversion官网下载页分两个入口，新版本在subversion.apache.org/download/，老版本归档在archive.apache.org/dist/subversion/。我在银河麒麟上第一次用的是当时的最新版，编译时报错提示需要更高版本的GCC或某些系统库，换回1.8.14反而一路通畅。这里不是说新版不好，而是源码编译场景下，老版本对系统库的依赖更宽松，尤其在国产化系统上省去很多找依赖的时间。
需要下载的源码包一共三个：
subversion-1.8.14.tar.gz，这是SVN本体apr-1.6.5.tar.gz，Apache可移植运行时库apr-util-1.6.1.tar.gz，APR的扩展工具库
把这三个包下载后，通过scp或U盘拷到服务器的/home/dmdba/svn/目录下。这个路径只是我习惯用的，你可以换成任意有写权限的目录，但建议中间不要有中文或空格。
2.2 安装目录规划：--prefix参数决定后续所有路径
编译安装前先想清楚安装到哪，因为--prefix一旦定下来，后续环境变量、服务启动脚本都要跟着这个路径走。我的规划是：
- APR装到
/usr/local/apr - APR-Util装到
/usr/local/apr-util - Subversion装到
/usr/local/svn
这样的好处是三个组件各自独立目录，将来要卸载或升级，直接删目录就行，不会污染系统其他位置。
切换到/home/dmdba/svn/apr-1.6.5目录，执行标准三步编译：
cd /home/dmdba/svn/apr-1.6.5 ./configure --prefix=/usr/local/apr make && make installmake && make install这个写法表示前一条命令成功后才执行后一条，避免编译失败后还把残缺文件装进系统。--prefix=/usr/local/apr指定安装根目录，后续头文件会放到/usr/local/apr/include，库文件放到/usr/local/apr/lib。
2.3 APR-Util和SVN的编译顺序
编译完APR之后不要急着编译Subversion，必须先把APR-Util装好，因为Subversion的./configure脚本会同时检查这两个依赖库的路径。
cd /home/dmdba/svn/apr-util-1.6.1 ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr make && make install注意这里的差异：--with-apr=/usr/local/apr告诉编译系统APR已经装在哪里了，这个参数是必需的，否则APR-Util会尝试在系统默认路径下找APR，然后大概率找不到。
接下来编译Subversion本体：
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 make && make install编译时长取决于机器性能，一般10到30分钟。如果中途报错缺少sqlite相关头文件，说明系统里没有安装SQLite开发包，需要先处理这个问题。我实际碰到的情况是系统里已经有了老版本SQLite运行库但没有头文件，需要额外安装sqlite-devel这类包。
2.4 环境变量：不配好就等着"command not found"
编译安装完成后，svnserve命令默认不会出现在PATH里，因为安装路径是/usr/local/svn/bin，不在系统默认搜索范围内。需要手动编辑/etc/profile文件：
vim /etc/profile在文件末尾追加一行：
PATH=$PATH:/usr/local/svn/bin保存退出后执行source /etc/profile让配置立即生效。这里有个容易忽略的细节：$PATH前面的美元符号不能省，否则会覆盖整个PATH变量，导致连ls、vim这些基础命令都找不到了，到时候只能靠绝对路径救回来。
验证是否配置成功：
svnserve --version如果能看到版本号输出，说明编译和路径配置都没问题了。
3. 初始化版本库：svnadmin create与目录结构说明
3.1 规划版本库根目录
版本库根目录和版本库本身是两层概念。根目录只是用来放多个项目版本库的容器，我一般把根目录设为/home/svn，每一个受管项目在它下面建一个子目录。
mkdir -p /home/svn/project-p参数的意思是如果/home/svn不存在则一并创建。这样以后要加第二个项目，就再建一个/home/svn/another_project，每个项目独立版本库互不干扰。
3.2 svnadmin create执行后发生了什么
把project目录变成版本库：
svnadmin create /home/svn/project执行后project目录下会多出这些文件和目录：
conf/：版本库配置文件目录，包括svnserve.conf、passwd、authzdb/：版本数据存储目录，SVN的实际数据都存在这里hooks/：钩子脚本目录，用于在提交等操作时触发自定义脚本locks/：锁目录，管理并发访问锁format：记录版本库格式版本号
这里要提醒你的是，不要试图手动修改db/目录里的任何文件。我见过有人为了"修复"提交报错直接去动db/revs里的文件，结果整个版本库直接废掉，只能从备份恢复。版本库的数据完整性交给SVN自己管理就行。
3.3 conf目录：三个文件各管一件事
版本库建好后，默认的conf/svnserve.conf里所有配置项都被注释掉了，passwd和authz是空的或全注释状态。要让它能被客户端访问且按预期控制权限，必须改这三个文件。
在动手配置前先明确各自职责：
svnserve.conf：SVN服务的总开关，控制匿名访问策略、认证方式、密码文件路径、权限文件路径passwd：存放用户名和密码的明文文件（SVN默认不加密）authz：存放路径级权限规则，决定谁能读谁能写
4. 配置svnserve.conf、passwd和authz：权限模型从零到可用
4.1 svnserve.conf：顶行写注释也踩坑
编辑/home/svn/project/conf/svnserve.conf，把以下四项配置的注释去掉并修改：
[general] anon-access = none auth-access = write password-db = passwd authz-db = authz四行配置的含义分别是：
anon-access = none：禁止匿名用户访问，客户端如果没有账号密码，连接会被直接拒绝auth-access = write：通过认证的用户拥有写权限password-db = passwd：指定用户密码文件用当前目录下的passwdauthz-db = authz：指定权限规则文件用当前目录下的authz
这里有一个必须牢记的坑：配置项必须顶行写，前面不能有空格。我当时图省事在[general]下面留了一个缩进，结果SVN服务端直接提示配置文件格式错误。同样的，注释也不要放在配置项后面用空格隔开，有些版本解析器会不认。
4.2 passwd：第一个账号的诞生
编辑conf/passwd文件，添加用户：
[users] admin = 123456[users]是固定小节名，下面是用户名 = 密码的格式。这里两个"坑"要说清楚：一是SVN的密码是明文存储的，不要在这里放跟系统root一样的密码；二是测试阶段先建一个用户就够了，等跑通整个流程再批量加人。
4.3 authz：先理解[/]代表什么
编辑conf/authz文件，内容如下：
[groups] g_admin = admin [/] @g_admin = rw * =[groups]小节用来定义用户组，把admin放进g_admin组。[/]表示整个版本库根目录。@g_admin = rw表示这个组对根目录有读写权限。最后的* =表示其他所有用户没有任何权限。
如果你有多个项目共用一个版本库根目录，[/]可以细化为[/project]、[/another_project]，实现项目间权限隔离。我实际做的时候还遇到过一个问题：authz文件里忘记写* =这一行，结果在anon-access = none的情况下，未匹配的用户直接报权限验证失败，日志里什么有用的信息都没有，排查了很久才发现是漏了这一条。
4.4 启动服务：svnserve的-d和-r参数不要写反
配置完成后启动服务：
svnserve -d -r /home/svn-d是后台守护进程模式，-r /home/svn指定版本库根目录。注意-r后面的路径一定要写到根目录，不是某个具体项目目录。如果写成了/home/svn/project，那么客户端访问时要写成svn://IP地址/project而非svn://IP地址/project/project，访问路径会和目录层级对不上。
启动后第一时间确认进程状态：
ps -ef | grep svnserve正常输出里能看到一行包含svnserve -d -r /home/svn的记录。如果什么输出都没有，多半是配置文件的格式问题，回头检查svnserve.conf的顶行和空格。
5. 避坑：银河麒麟上SVN服务连不上的常见问题
5.1 现象：客户端报"Connection refused"
原因：服务没启动，或者防火墙把3690端口拦掉了。
解决：先确认服务进程是否存在，没有就启动。如果进程存在但还是被拒绝，检查防火墙配置。
iptables -nL | grep 3690没有输出就说明端口没放行，执行放行命令。
5.2 现象：认证通过但提交时报"Authorization failed"
原因：authz里* =这一行缺失，或者[/]路径写错导致权限规则没匹配上。
解决：回到authz文件重新核对，[/]的/前后不要加多余空格。改了配置后不需要重启服务，SVN会在下一次请求时重新解析权限文件。如果你发现改了还是报同样的错，用svnserve的前台模式启动看日志输出来定位。
5.3 现象：svnserve.conf写了配置但svnadmin create还是失败
原因：这俩根本不是一个阶段的东西。svnadmin create是版本库初始化，完全不读三个配置文件，只负责生成目录骨架。
解决：意识到这个报错大概率是svnadmin路径没对上，检查which svnadmin的输出是不是/usr/local/svn/bin/svnadmin。如果不是，说明环境变量配了但当前shell没重新加载。
5.4 现象：开机重启后SVN服务没了
原因：没有做开机自启配置，svnserve进程随着系统重启而消失。
解决：写一个开机脚本并加入rc.local。
touch /root/svn.sh sudo bash -c 'echo "#!/bin/bash" > /root/svn.sh' sudo bash -c 'echo "/usr/local/svn/bin/svnserve -d -r /home/svn" >> /root/svn.sh' chmod 777 /root/svn.sh bash /root/svn.sh echo "/root/svn.sh" >> /etc/rc.d/rc.local脚本里的svnserve路径写绝对路径是重点，因为开机时环境变量可能还没加载完，which svnserve找到的路径不可靠。
5.5 现象：客户端连上了svn服务器但看不到任何项目
原因：访问路径写法不对。svn://IP/project能访问，svn://IP只会看到一个空列表。
解决：先确认svn://IP/project能正常访问，如果提示版本库不存在，看一下服务启动时-r参数是不是精确到了/home/svn/project，如果是，客户端路径就不要再带project了。
6. 从一次性安装到长期可用：验证提交与日常运维的四个习惯
版本库创建好、服务启动成功，这只是万里长征第一步。真正考验配置是否正确的方式，是从另一台机器上用svn checkout拉一次代码，再改个文件提交回去，跑通一次完整的读写流程。
从Windows客户端测试时，先装上任意一款SVN客户端软件，然后新建一个工作副本，地址填svn://服务器IP/project，弹出的认证窗口输入之前配置的admin/123456。如果checkout成功，就说明整条链路已经通了。
提交测试时建议建一个README.txt，写一行内容提交上去，然后改掉内容再次提交，确认authz里的rw权限真正生效。
从那以后我每次在银河麒麟或其他类CentOS系统上搭SVN，都强制走一遍这个验证流程：先编译安装，再svnadmin create，再配置文件，最后一定做一次从零checkout和提交。这个习惯帮我快速定位过好几回问题，比如有一次提交报错查了半天才发现是authz里的路径写成了[/project/]多了一个斜杠。
日常运维中，配置文件改动前先备份一份再动，是保证版本库安全的重要习惯。我把每次配置变更都会先复制一份加上时间戳后缀，一旦改坏能快速回滚。另外svnserve.conf的顶行规范和authz的* =兜底规则，我都会在交付给下一个同事时重点口头交代一遍，这两个位置是新手最容易踩的坑。
SVN这套方案虽然看起来步骤多，但每个步骤都是确定性的，不涉及模糊参数。按照上面的顺序走，从下载源码包到客户端能访问，整个过程大概一小时左右。最浪费时间的地方往往不是编译本身，而是编译前的依赖检查和编译后配置文件的格式问题。希望这篇笔记能帮你在银河麒麟上把SVN一次装通。
本文还有配套的精品资源，点击获取
