1. 为什么“装个新版 SVN”这件事值得单独写一篇CentOS 7 上装 Subversion看起来是个再普通不过的运维动作yum install subversion一行命令的事。但真正在生产环境里动过手的人都知道这条命令装出来的是 1.7.14一个 2014 年就定版的版本。放到今天这个版本号意味着什么意味着你从新版客户端提交上来的svn:mergeinfo属性它可能解析不了意味着--accept参数不认意味着svn auth这种缓存凭据的子命令压根不存在更别说某些新版才有的--search日志过滤能力。更麻烦的是CentOS 7 已经在 2024 年 6 月正式结束维护官方源、EPEL 源的元数据镜像陆续下线或迁移很多机器上yum makecache直接报错你想装旧版都装不顺利。这时候摆在面前的只有两条路要么忍着一堆兼容性告警用老版本要么从源码或者第三方仓库把新版 SVN 拉起来。这篇内容就是把这第二条路走通的全过程摊开讲。我不打算只给你几条命令让你复制粘贴因为复制粘贴在编译安装这件事上翻车的概率极高——编译参数少一个--with-apr后面跟 Apache 集成的时候就是一堆找不到头文件的报错依赖没装全configure 阶段看着过了make 到一半才崩。所以我会把每个参数为什么这么给、依赖为什么要单独指定路径、遇到报错怎么反推原因全部交代清楚。适合谁看一是手上还有 CentOS 7 存量机器、需要维持 SVN 服务可用的运维同学二是要在内网搭一套代码版本管理、又不想上 Git 那套学习曲线的小团队三是单纯想搞明白“源码编译安装”这套流程到底怎么回事、以后换别的软件也能照葫芦画瓢的读者。哪怕你之前只敲过yum install跟着走也能装出来因为每一步我都会说明白它想解决什么问题。需要提前说明的是下面所有的路径、版本号、依赖组合都是基于“一台干净的最小化安装 CentOS 7”这个前提推导的如果你的机器上已经装过 Apache、已经编译过其他带 apr 的软件部分步骤需要做适配我会在对应位置标出来。2. 安装方案选型源码编译、第三方仓库还是容器化2.1 三条路的成本账先算清楚再动手在 CentOS 7 上拿到新版 SVN实际可走的路线有三条每条路的维护成本和风险完全不同先摆个表对比省得你走了一半才发现选错。方案版本可控性上线耗时后续升级主要风险适用场景源码编译安装完全可控想装哪个版本装哪个30~60 分钟需重新编译可保留旧版并行依赖路径错配、动态库找不到单机部署、需要特定版本、要与 Apache 集成第三方仓库如 wandisco 类受仓库维护方限制5~10 分钟yum update即可仓库停更或下线后彻底断供临时过渡、对版本要求不严格容器化运行完全可控镜像即版本10~20 分钟换镜像标签需额外维护容器运行时与数据卷新环境、愿意引入容器体系我个人的取舍逻辑很直接如果这台机器要长期跑、要跟 Apache 的 mod_dav_svn 绑在一起对外提供 HTTP 访问那源码编译是唯一让人睡得着的方案。原因在于 mod_dav_svn 是一个 Apache 模块它必须和 SVN 的库版本严格对应你从第三方仓库装了个新版 SVN但系统里的 Apache 还是 httpd 2.4.6模块 ABI 对不上加载时会直接报undefined symbol。而源码编译的时候你可以精确指定 Apache 的 apxs 路径让模块针对当前这个 httpd 编译一次到位。第三方仓库那条路的问题在于不可控。这类仓库本质是有人替你编译好了 rpm 包但它什么时候停止维护、会不会哪天仓库地址 404你完全没法左右。对于内网里跑了好几年、没人愿意再动的老机器一旦仓库断供你连回滚都麻烦。容器化确实是干净方案但它引入了一个新问题SVN 的仓库数据你要挂在卷上权限映射要处理好而且很多老环境里根本不允许装容器运行时。所以它更适合新搭的环境而不是给存量机器做升级。提示如果你的目标只是“客户端能用新版命令”不涉及服务端和 Apache 集成那其实可以不折腾服务端直接编译一个客户端装到/usr/local下用绝对路径调用跟系统自带的 1.7 并存互不干扰。这个思路能省掉一大半麻烦。2.2 为什么最终锁定源码编译这条线确定了源码编译还有个隐含选择装到系统默认路径/usr还是独立路径/usr/local。这个决定影响很大我建议一律选/usr/local理由有三条。第一避免覆盖系统包管理器管理的文件。CentOS 的 rpm 数据库记录了/usr/bin/svn属于哪个包你如果直接覆盖后续yum做任何操作都可能报文件冲突严重的会让包管理器进入半坏状态修起来比重装还费劲。第二便于回滚和并存。装到/usr/local/bin/svn之后系统原来的/usr/bin/svn还在你只需要调整 PATH 顺序或者用绝对路径就能在新旧之间切换。万一新版有兼容问题改回 PATH 立刻恢复不用卸载重装。第三跟 Apache 的集成更清晰。用--with-apxs指定系统的 apxsmod_dav_svn.so 会被装到 Apache 的模块目录配置文件里加一行 LoadModule 就能用不会跟发行版自带的 subversion 包产生文件归属纠纷。第三点特别值得展开说。CentOS 7 自带的 httpd 是 2.4.6如果你之前用 yum 装过mod_dav_svn那/etc/httpd/conf.modules.d/下会有一个10-subversion.conf里面指向的是系统自带版本的模块。你编译新版的时候如果没注意装完会出现两个模块文件抢同一个模块名的情况Apache 启动报module dav_svn_module is already loaded。解决办法很简单编译前先把系统自带的 subversion 相关包卸干净或者至少把那个 conf 文件挪走备份。这个坑我在第一次做的时候踩过排查了快一个小时才定位到是模块重复加载。另外补充一个判断依据如果你执行rpm -qa | grep subversion有输出说明系统里有 rpm 版的 SVN编译之前务必处理掉否则头文件路径会串。rpm -e --nodeps subversion subversion-libs可以强卸但卸之前确认没有别的软件依赖它用rpm -q --whatrequires subversion查一下比较稳妥。3. 编译前的环境准备与依赖梳理3.1 最小化系统缺什么一次补齐最小化安装的 CentOS 7 上编译 SVN 需要的依赖一个都没有得手动补。这里我把依赖分成三类来讲因为它们的角色不同缺了报的错也不一样。第一类是编译工具链gcc、gcc-c、make、autoconf、automake、libtool。这些是基础缺了连 configure 都跑不起来。libtool特别容易被漏掉因为它不是编译 SVN 本体需要的而是编译 apr、apr-util 这些依赖时需要报错信息还特别隐蔽通常在libtool: command not found这种地方才暴露。第二类是 SVN 运行时依赖的库zlib-devel压缩传输、libtool-ltdl-devel动态加载、expat-develXML 解析SVN 的配置文件是 XML 格式、sqlite-devel工作副本的元数据存储1.7 之后工作副本就是 sqlite 数据库了、openssl-develHTTPS 访问仓库必需。第三类是 apr 和 apr-util这两个是 Apache 的可移植运行库SVN 强依赖。系统里虽然有但版本偏老我建议一起编译新的原因后面细说。一次性装完的命令yum install -y gcc gcc-c make autoconf automake libtool \ zlib-devel libtool-ltdl-devel expat-devel sqlite-devel \ openssl-devel perl-core perl-develperl-core和perl-devel是给 SVN 的 Perl 绑定用的如果你确定不用 Perl 脚本操作 SVN可以在 configure 时加--without-swig跳过但装了也不亏反正体积不大。注意CentOS 7 官方源已停止维护yum install大概率报Cannot find a valid baseurl。这时候要么换成 vault 归档源要么挂载系统安装 ISO 作为本地源。我一般选后者因为不依赖网络、速度快、稳定。挂载命令是mount -o loop /path/to/CentOS-7-x86_64-DVD.iso /mnt然后写一个指向/mnt的 repo 文件gpgcheck0关掉校验直接装。3.2 apr 和 apr-util 为什么要单独编译这是源码编译 SVN 时最容易含糊过去的一步很多人直接用系统自带的 aprconfigure 也能过但后面会出问题。系统自带的 apr 版本是 1.4.8apr-util 是 1.5.2而新版 SVN 依赖的 apr 至少 1.5.x。更关键的是如果你编译时链接的是系统 apr但运行时因为LD_LIBRARY_PATH或者ldconfig缓存的原因加载到了另一个版本的 apr就会出现典型的undefined symbol: apr_xxx报错。这种错误在启动 svnserve 或者 Apache 加载 mod_dav_svn 时才会暴露排查起来很痛苦。我的做法是下载 apr 和 apr-util 的源码编译安装到/usr/local/apr然后在 configure SVN 时显式指定--with-apr/usr/local/apr和--with-apr-util/usr/local/apr。这样编译期和运行期的库路径完全一致杜绝版本错配。编译 apr 的命令序列tar -xzf apr-1.7.4.tar.gz cd apr-1.7.4 ./configure --prefix/usr/local/apr make make install tar -xzf apr-util-1.6.3.tar.gz cd apr-util-1.6.3 ./configure --prefix/usr/local/apr --with-apr/usr/local/apr make make install注意 apr-util 的--with-apr必须指向前一步装好的位置否则它可能去找系统自带的 apr编译出来的东西又混了。装完之后为了让动态链接器能找到这些库需要加一个配置文件到/etc/ld.so.conf.d/echo /usr/local/apr/lib /etc/ld.so.conf.d/apr.conf ldconfig这一步不做后面 svn 启动会报error while loading shared libraries: libapr-1.so.0。ldconfig会刷新缓存让新路径生效。验证方法是ldconfig -p | grep apr能看到/usr/local/apr/lib下的库就算成功。3.3 sqlite 的版本陷阱这个必须单独拎出来说因为它坑过太多人。SVN 1.7 之后工作副本的元数据从.svn/entries文件换成了.svn/wc.db这个 SQLite 数据库。所以 SVN 对 SQLite 有强依赖。问题是SVN 自带一个内嵌的 sqlite amalgamation编译时默认会优先用它而不是系统里的sqlite-devel。带来的后果是你系统里可能装着 sqlite 3.7.x但 SVN 编出来用的是它内嵌的另一个版本。表面上看没问题直到你用某些工具比如一些 IDE 的 SVN 插件、或者自己写的脚本直接读wc.db发现版本不兼容数据库打不开。解决办法是在 configure 时显式加--with-sqlite/usr强制让它用系统的 sqlite。当然前提是你sqlite-devel已经装好了。验证方式是编译完之后执行svn --version --verbose输出里会列出- using SQLite 3.x.x对比一下是不是你系统里那个版本。如果你嫌麻烦也可以用默认的内嵌版本功能上没问题只是在跟第三方工具协作时多一层不确定性。我个人倾向指定系统库因为出问题时至少能通过yum info sqlite确认版本。4. 核心编译参数的逐项拆解4.1 configure 参数不是越多越好每个都要有理由很多人从网上抄一段 configure 参数长长一串自己都不知道每个是干嘛的。我这边给的参数集是精简过的每一项都有明确目的你按需增减。./configure \ --prefix/usr/local/subversion \ --with-apr/usr/local/apr \ --with-apr-util/usr/local/apr \ --with-sqlite/usr \ --with-apxs/usr/bin/apxs \ --with-ssl \ --enable-shared \ --disable-static \ --without-javahl逐项解释--prefix/usr/local/subversion指定安装根目录。我习惯单独建一个目录而不是直接/usr/local这样卸载的时候rm -rf一个目录就干净了不会跟/usr/local/bin下其他软件混在一起。--with-apr和--with-apr-util指向前一步编译的 apr 路径保证库一致。--with-sqlite/usr强制用系统 sqlite理由上面讲过了。--with-apxs/usr/bin/apxs是关键项。apxs 是 Apache 的扩展工具SVN 用它来编译 mod_dav_svn 模块。指定了这个路径编译过程会去读 Apache 的配置拿到正确的头文件位置和模块目录编出来的.so就能直接被 Apache 加载。如果你机器上没装 httpd-develapxs 不存在这一项会失败所以编译前先yum install -y httpd httpd-devel。--with-ssl启用 HTTPS 支持访问https://开头的仓库必需。它依赖openssl-devel没装的话 configure 会报OpenSSL not found。--enable-shared --disable-static生成动态库而不是静态库。动态库体积小多个程序可以共享升级也方便。静态库除了少数嵌入场景基本用不上。--without-javahl跳过 Java 绑定。JavaHL 是给 Java 程序通过 JNI 调用 SVN 用的编译它需要 JDK 和 SWIG链条很长。除非你有 Java 应用需要嵌入 SVN 客户端否则一律跳过能省十几分钟编译时间和一堆依赖。提示如果你只想要客户端、不要服务端和 Apache 集成可以把--with-apxs去掉加--without-apache。这样编译更快产物也更简洁。但注意 svnserve 服务端还是会编出来它是独立于 Apache 的。4.2 参数给错时的典型报错对照configure 阶段的报错信息有时候很绕我整理了实际遇到过的几种对着看能少走弯路。报错关键字真实原因处理方式cannot find APR--with-apr路径给错或 apr 没装确认/usr/local/apr/bin/apr-1-config存在且可执行APR-util not found同上或 apr-util 编译时没指对 apr重编 apr-util--with-apr必须是正确路径OpenSSL not found缺openssl-devel或 pkg-config 找不到装包后确认openssl version正常必要时加--with-openssl/usrsqlite3 not found缺sqlite-devel或--with-sqlite路径错装包检查/usr/include/sqlite3.h是否存在apxs: not found缺httpd-develyum install -y httpd-devel确认/usr/bin/apxs存在expat.h not found缺expat-devel装包它的头文件在/usr/include/expat.h这个表建议截图存着。我印象最深的一次是 apr-util 编译时--with-apr给了一个不存在的目录configure 居然不报错而是默默回退到去找系统 apr编译出来的 apr-util 跟新 apr 不匹配到 SVN configure 阶段才报invalid apr version往回倒查了好几层才找到根源。所以依赖编译阶段就要验证产物别等到最后一步。具体怎么验证 apr 编译对不对装完之后执行/usr/local/apr/bin/apr-1-config --version /usr/local/apr/bin/apr-1-config --prefix两个输出对得上/usr/local/apr就说明没问题。apr-util 同理用/usr/local/apr/bin/apu-1-config --with-apr能看到它链接的是哪个 apr。5. 从编译到验证的完整实操记录5.1 编译与安装的执行过程依赖齐了、参数定了真正跑起来就三步。但每步的输出都要留意出问题第一时间能定位。第一步下载源码。SVN 的源码包在 Apache 的归档站点上文件名形如subversion-1.14.3.tar.gz。下载完先校验sha256sum对比官方公布的哈希值别嫌麻烦压缩包损坏导致 make 阶段莫名报错的情况我遇到过一次白折腾半小时。tar -xzf subversion-1.14.3.tar.gz cd subversion-1.14.3第二步configure。把前面定好的参数贴进去执行输出会滚动很长一串检查结果。重点看结尾那几行它会列出启用了哪些特性Configured for: ... Apache module: yes Berkeley DB: no ... SSL support: yes Plaintext password storage: yes ...确认Apache module是 yes如果你需要的话SSL support是 yes。有不对的地方现在改还来得及make 之后再改就得make clean重来。第三步make make install。编译过程视机器性能而定单核大约 5~8 分钟。编译期间会有一些 warning大多是代码风格提示不影响结果不用管。真正要警惕的是 error一旦出现会立即终止。装完之后把新版本的 bin 目录加进 PATHecho export PATH/usr/local/subversion/bin:$PATH /etc/profile.d/subversion.sh source /etc/profile.d/subversion.sh用/etc/profile.d/而不是直接改~/.bashrc是为了让所有用户都能用上新命令。写进去之后新开的 shell 自动生效已经打开的 shell 需要 source 一下。5.2 验证清单从版本号到实际提交装完不等于能用我习惯跑一套验证清单五项过关才算真装好了。# 1. 版本号 svn --version --verbose # 2. 确认链接的库路径重点看 apr 和 sqlite ldd /usr/local/subversion/bin/svn | grep -E apr|sqlite|ssl # 3. 服务端版本 svnserve --version # 4. Apache 模块是否装到位 ls -l /usr/lib64/httpd/modules/mod_dav_svn.so # 5. 取模块的依赖是否齐全 ldd /usr/lib64/httpd/modules/mod_dav_svn.so第 2 步的输出最能说明问题。如果libapr-1.so.0指向的是/usr/local/apr/lib/下的说明库链接正确如果指向/usr/lib64/那说明它用的还是系统 apr前面指定--with-apr可能没生效得回头查。第 5 步也容易出问题。mod_dav_svn.so 依赖很多库ldd如果输出里有not foundApache 加载这个模块时会直接失败。常见的是libsvn_*.so找不到原因是/usr/local/subversion/lib不在链接器的搜索路径里。解决办法是把它也加进ld.so.conf.decho /usr/local/subversion/lib /etc/ld.so.conf.d/subversion.conf ldconfig全部验证通过后最实在的一步是实际建个仓库、提交一次验证端到端能跑通mkdir -p /data/svn/myrepo svnadmin create /data/svn/myrepo svn co file:///data/svn/myrepo /tmp/wc cd /tmp/wc echo test readme.txt svn add readme.txt svn ci -m init commit --username admin如果这一步能成功说明客户端、服务端、库文件全部就位。5.3 跟 Apache 集成时的配置要点要让 SVN 通过 HTTP 对外提供服务需要三个 moduledav_module、dav_svn_module、authz_svn_module。在 Apache 的配置目录下建一个文件比如/etc/httpd/conf.d/svn.confLoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so Location /svn DAV svn SVNParentPath /data/svn SVNListParentPath On AuthType Basic AuthName Subversion Repository AuthUserFile /etc/svn-auth-file Require valid-user /Location这里有个细节LoadModule dav_module可能会跟 Apache 默认配置里的重复报already loaded。解决方式是在 httpd.conf 里找到原有的那行或者用IfModule !dav_module包一层。实际部署时我一般先 grep 一遍/etc/httpd/下所有的 LoadModule确认没有重复。用户认证文件用 htpasswd 生成htpasswd -cm /etc/svn-auth-file admin htpasswd -m /etc/svn-auth-file dev01-c只在第一次创建时加后面再加用户千万别带-c否则会把文件覆盖掉前面的用户全没了。这个错我见过不止一次属于典型的粗心翻车。配置改完先httpd -t检查语法通过再systemctl reload httpd。如果 reload 失败systemctl status httpd看错误或者直接看/var/log/httpd/error_log模块加载失败的详细原因都在里面。6. 踩过的坑与排查实录6.1 动态库找不到的三类表现编译安装最集中的问题就是运行时报找不到动态库表现有三种处理方式略有不同。第一种svn命令直接报error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file。这是 SVN 自己的库没被找到因为--prefix装到了/usr/local/subversion而这个路径不在默认搜索范围内。处理就是前面说的加ld.so.conf.d配置然后ldconfig。第二种svn能跑但执行某个操作比如 https 访问时报libssl.so相关错误。这是因为它链接的 SSL 库版本跟运行环境不一致。用ldd查具体是哪个库确认路径后再针对性处理。第三种Apache 加载 mod_dav_svn 时报undefined symbol: svn_repos_xxx。这说明模块编译时链接的 SVN 库版本和运行时加载的版本不一致。多半是系统里还残留着旧版 SVN 的库文件加载时串了。用find / -name libsvn_repos*找一遍把旧版本的删掉或者挪走。这三种情况的共同点是编译期和运行期的库路径必须一致。所以我前面强调 apr 和 sqlite 都显式指定路径就是为了减少这类不一致。6.2 Apache 启动失败的排查顺序Apache 起不来错误日志一般写得比较清楚但原因可能藏在好几层。我的排查顺序是这样的先看systemctl status httpd它会给出退出码和最直接的错误行。如果是AH00526: Syntax error那就是配置文件语法问题httpd -t会告诉你在第几行。如果是Cannot load modules/mod_dav_svn.so往下看。接着ldd /usr/lib64/httpd/modules/mod_dav_svn.so | grep not found有输出说明依赖库缺失缺什么补什么。然后确认模块文件本身存在且权限正确ls -l看一下一般是root:root 755。最后看是不是模块重复加载grep -r dav_svn_module /etc/httpd/搜一遍如果两个文件都写了 LoadModule注释掉一个。这个顺序的逻辑是从粗到细先排除语法和文件层面的低级问题再查依赖这种深层问题。按这个顺序走大部分启动失败十分钟内能定位。6.3 常见问题速查表现象可能原因快速处理svn: command not foundPATH 没生效source /etc/profile.d/subversion.sh或绝对路径调用svn --version显示的还是旧版PATH 顺序问题旧路径在前检查echo $PATH把新路径移到前面svnadmin create报权限错误目标目录属主不对chown -R apache:apache /data/svnHTTP 模式或对应运行用户提交时提示Authorization failedauthz 配置或 htpasswd 文件问题确认用户名密码、检查AuthUserFile路径和权限644中文提交信息乱码终端编码或仓库编码设置确认LANG为 UTF-8仓库默认按 UTF-8 存储yum报Cannot find a valid baseurl官方源已下线挂载 ISO 做本地源或换 vault 归档地址编译时make卡住不动内存不足多核并行编译撑爆改用make -j2或单线程make6.4 两条不太常见但很值得记的经验第一条不要在同一台机器上同时保留新旧两套 SVN 的 Apache 模块。我试过让新旧并存想着切换方便结果 Apache 配置怎么写都只能加载其中一个因为模块名相同先加载的生效。后来干脆放弃并存服务端只保留一套客户端才允许多版本共存。第二条升级前先用svnadmin hotcopy备份仓库。虽然 SVN 的仓库格式向后兼容做得不错新版能直接读旧版仓库但反过来不行。一旦升级到新版开始写入再用旧版svnadmin操作就可能出问题。hotcopy是原子性复制整个仓库目录比cp -r更安全因为它处理了锁文件和临时文件的情况。备份命令svnadmin hotcopy /data/svn/myrepo /backup/svn/myrepo-$(date %F)这个操作不需要停服务跑完再把新版指过去是最稳妥的升级姿势。我在一次跨版本升级里就是因为没做这步新版写入了新格式的 revision props回滚时旧版读不懂最后只能从更早的一次备份恢复丢了两天的提交记录。这个教训值得每个人都记一下。7. Perl 绑定与可选组件的取舍7.1 Perl 绑定到底要不要装configure 默认会尝试编译 Perl 绑定因为它找不到就会跳过所以很多人没注意过它的存在。但如果你机器上有 Perl 开发环境它会默默编出来然后在你make install时往 Perl 的 site_perl 目录里塞一堆模块。这件事本身不坏坏在版本管理混乱。系统自带的 Perl 模块目录由 rpm 管理你手工装进去的模块会跟后续的yum update产生冲突。所以我的建议是明确决定要还是不要用参数说清楚别让它自己判断。要的话加--with-swig前提是装了swig包。它的作用是给 Perl、Python 等语言生成绑定代码。不要的话加--without-swig编译会干净很多速度也快。如果你确实需要用脚本批量操作 SVN比如自动导出某个版本、批量打 tag那 Perl 绑定SVN::Client或者 Python 绑定svn模块都挺方便。但这种场景用svn命令行配合 shell 脚本也能做而且更直观、更容易调试。我个人倾向不装绑定需要自动化就用命令行包一层出错时看日志也直观。7.2 Berkeley DB 和 FSFS 的选择SVN 支持两种仓库后端Berkeley DB 和 FSFS。老版本时代有过争论现在没什么悬念了——一律用 FSFS也就是svnadmin create的默认行为不需要任何额外操作。Berkeley DB 的问题在于它是嵌入式数据库需要独占文件锁一旦进程异常退出留下锁文件仓库就锁死了得手工清理。而且它对文件系统的依赖比较微妙NFS 上跑基本等于找罪受。FSFS 是纯文件存储每个 revision 一个文件好处是跨文件系统兼容性好、备份简单直接拷目录、并发读写更稳。configure 时如果不想编 Berkeley DB 支持加--without-berkeley-db。默认它可能会检测系统里的 db4 库然后启用了编出来体积大一些还多一层依赖。显式关掉更清爽。7.3 装完之后做一次精简清理make install之后源码目录会留下编译中间文件占几百 MB 空间。确认安装无误后可以直接删掉cd /path/to/source make clean如果连源码都不打算留rm -rf整个目录也行。但建议保留源码包和 configure 参数记录因为后续如果要在同环境再装一台照着参数重跑一遍就行不用重新回忆当时怎么配的。我习惯把 configure 那行命令写进一个build.sh脚本存档下次直接改版本号执行。另外/usr/local/subversion目录下有不少运行时用不到的文件比如include/头文件、share/文档如果机器磁盘紧张可以删但不建议——留着它们以后要编译依赖 SVN 库的第三方程序比如某些 IDE 的 SVN 插件要自己编时直接就能用省得再装一遍开发包。
1. 为什么“装个新版 SVN”这件事值得单独写一篇CentOS 7 上装 Subversion看起来是个再普通不过的运维动作yum install subversion一行命令的事。但真正在生产环境里动过手的人都知道这条命令装出来的是 1.7.14一个 2014 年就定版的版本。放到今天这个版本号意味着什么意味着你从新版客户端提交上来的svn:mergeinfo属性它可能解析不了意味着--accept参数不认意味着svn auth这种缓存凭据的子命令压根不存在更别说某些新版才有的--search日志过滤能力。更麻烦的是CentOS 7 已经在 2024 年 6 月正式结束维护官方源、EPEL 源的元数据镜像陆续下线或迁移很多机器上yum makecache直接报错你想装旧版都装不顺利。这时候摆在面前的只有两条路要么忍着一堆兼容性告警用老版本要么从源码或者第三方仓库把新版 SVN 拉起来。这篇内容就是把这第二条路走通的全过程摊开讲。我不打算只给你几条命令让你复制粘贴因为复制粘贴在编译安装这件事上翻车的概率极高——编译参数少一个--with-apr后面跟 Apache 集成的时候就是一堆找不到头文件的报错依赖没装全configure 阶段看着过了make 到一半才崩。所以我会把每个参数为什么这么给、依赖为什么要单独指定路径、遇到报错怎么反推原因全部交代清楚。适合谁看一是手上还有 CentOS 7 存量机器、需要维持 SVN 服务可用的运维同学二是要在内网搭一套代码版本管理、又不想上 Git 那套学习曲线的小团队三是单纯想搞明白“源码编译安装”这套流程到底怎么回事、以后换别的软件也能照葫芦画瓢的读者。哪怕你之前只敲过yum install跟着走也能装出来因为每一步我都会说明白它想解决什么问题。需要提前说明的是下面所有的路径、版本号、依赖组合都是基于“一台干净的最小化安装 CentOS 7”这个前提推导的如果你的机器上已经装过 Apache、已经编译过其他带 apr 的软件部分步骤需要做适配我会在对应位置标出来。2. 安装方案选型源码编译、第三方仓库还是容器化2.1 三条路的成本账先算清楚再动手在 CentOS 7 上拿到新版 SVN实际可走的路线有三条每条路的维护成本和风险完全不同先摆个表对比省得你走了一半才发现选错。方案版本可控性上线耗时后续升级主要风险适用场景源码编译安装完全可控想装哪个版本装哪个30~60 分钟需重新编译可保留旧版并行依赖路径错配、动态库找不到单机部署、需要特定版本、要与 Apache 集成第三方仓库如 wandisco 类受仓库维护方限制5~10 分钟yum update即可仓库停更或下线后彻底断供临时过渡、对版本要求不严格容器化运行完全可控镜像即版本10~20 分钟换镜像标签需额外维护容器运行时与数据卷新环境、愿意引入容器体系我个人的取舍逻辑很直接如果这台机器要长期跑、要跟 Apache 的 mod_dav_svn 绑在一起对外提供 HTTP 访问那源码编译是唯一让人睡得着的方案。原因在于 mod_dav_svn 是一个 Apache 模块它必须和 SVN 的库版本严格对应你从第三方仓库装了个新版 SVN但系统里的 Apache 还是 httpd 2.4.6模块 ABI 对不上加载时会直接报undefined symbol。而源码编译的时候你可以精确指定 Apache 的 apxs 路径让模块针对当前这个 httpd 编译一次到位。第三方仓库那条路的问题在于不可控。这类仓库本质是有人替你编译好了 rpm 包但它什么时候停止维护、会不会哪天仓库地址 404你完全没法左右。对于内网里跑了好几年、没人愿意再动的老机器一旦仓库断供你连回滚都麻烦。容器化确实是干净方案但它引入了一个新问题SVN 的仓库数据你要挂在卷上权限映射要处理好而且很多老环境里根本不允许装容器运行时。所以它更适合新搭的环境而不是给存量机器做升级。提示如果你的目标只是“客户端能用新版命令”不涉及服务端和 Apache 集成那其实可以不折腾服务端直接编译一个客户端装到/usr/local下用绝对路径调用跟系统自带的 1.7 并存互不干扰。这个思路能省掉一大半麻烦。2.2 为什么最终锁定源码编译这条线确定了源码编译还有个隐含选择装到系统默认路径/usr还是独立路径/usr/local。这个决定影响很大我建议一律选/usr/local理由有三条。第一避免覆盖系统包管理器管理的文件。CentOS 的 rpm 数据库记录了/usr/bin/svn属于哪个包你如果直接覆盖后续yum做任何操作都可能报文件冲突严重的会让包管理器进入半坏状态修起来比重装还费劲。第二便于回滚和并存。装到/usr/local/bin/svn之后系统原来的/usr/bin/svn还在你只需要调整 PATH 顺序或者用绝对路径就能在新旧之间切换。万一新版有兼容问题改回 PATH 立刻恢复不用卸载重装。第三跟 Apache 的集成更清晰。用--with-apxs指定系统的 apxsmod_dav_svn.so 会被装到 Apache 的模块目录配置文件里加一行 LoadModule 就能用不会跟发行版自带的 subversion 包产生文件归属纠纷。第三点特别值得展开说。CentOS 7 自带的 httpd 是 2.4.6如果你之前用 yum 装过mod_dav_svn那/etc/httpd/conf.modules.d/下会有一个10-subversion.conf里面指向的是系统自带版本的模块。你编译新版的时候如果没注意装完会出现两个模块文件抢同一个模块名的情况Apache 启动报module dav_svn_module is already loaded。解决办法很简单编译前先把系统自带的 subversion 相关包卸干净或者至少把那个 conf 文件挪走备份。这个坑我在第一次做的时候踩过排查了快一个小时才定位到是模块重复加载。另外补充一个判断依据如果你执行rpm -qa | grep subversion有输出说明系统里有 rpm 版的 SVN编译之前务必处理掉否则头文件路径会串。rpm -e --nodeps subversion subversion-libs可以强卸但卸之前确认没有别的软件依赖它用rpm -q --whatrequires subversion查一下比较稳妥。3. 编译前的环境准备与依赖梳理3.1 最小化系统缺什么一次补齐最小化安装的 CentOS 7 上编译 SVN 需要的依赖一个都没有得手动补。这里我把依赖分成三类来讲因为它们的角色不同缺了报的错也不一样。第一类是编译工具链gcc、gcc-c、make、autoconf、automake、libtool。这些是基础缺了连 configure 都跑不起来。libtool特别容易被漏掉因为它不是编译 SVN 本体需要的而是编译 apr、apr-util 这些依赖时需要报错信息还特别隐蔽通常在libtool: command not found这种地方才暴露。第二类是 SVN 运行时依赖的库zlib-devel压缩传输、libtool-ltdl-devel动态加载、expat-develXML 解析SVN 的配置文件是 XML 格式、sqlite-devel工作副本的元数据存储1.7 之后工作副本就是 sqlite 数据库了、openssl-develHTTPS 访问仓库必需。第三类是 apr 和 apr-util这两个是 Apache 的可移植运行库SVN 强依赖。系统里虽然有但版本偏老我建议一起编译新的原因后面细说。一次性装完的命令yum install -y gcc gcc-c make autoconf automake libtool \ zlib-devel libtool-ltdl-devel expat-devel sqlite-devel \ openssl-devel perl-core perl-develperl-core和perl-devel是给 SVN 的 Perl 绑定用的如果你确定不用 Perl 脚本操作 SVN可以在 configure 时加--without-swig跳过但装了也不亏反正体积不大。注意CentOS 7 官方源已停止维护yum install大概率报Cannot find a valid baseurl。这时候要么换成 vault 归档源要么挂载系统安装 ISO 作为本地源。我一般选后者因为不依赖网络、速度快、稳定。挂载命令是mount -o loop /path/to/CentOS-7-x86_64-DVD.iso /mnt然后写一个指向/mnt的 repo 文件gpgcheck0关掉校验直接装。3.2 apr 和 apr-util 为什么要单独编译这是源码编译 SVN 时最容易含糊过去的一步很多人直接用系统自带的 aprconfigure 也能过但后面会出问题。系统自带的 apr 版本是 1.4.8apr-util 是 1.5.2而新版 SVN 依赖的 apr 至少 1.5.x。更关键的是如果你编译时链接的是系统 apr但运行时因为LD_LIBRARY_PATH或者ldconfig缓存的原因加载到了另一个版本的 apr就会出现典型的undefined symbol: apr_xxx报错。这种错误在启动 svnserve 或者 Apache 加载 mod_dav_svn 时才会暴露排查起来很痛苦。我的做法是下载 apr 和 apr-util 的源码编译安装到/usr/local/apr然后在 configure SVN 时显式指定--with-apr/usr/local/apr和--with-apr-util/usr/local/apr。这样编译期和运行期的库路径完全一致杜绝版本错配。编译 apr 的命令序列tar -xzf apr-1.7.4.tar.gz cd apr-1.7.4 ./configure --prefix/usr/local/apr make make install tar -xzf apr-util-1.6.3.tar.gz cd apr-util-1.6.3 ./configure --prefix/usr/local/apr --with-apr/usr/local/apr make make install注意 apr-util 的--with-apr必须指向前一步装好的位置否则它可能去找系统自带的 apr编译出来的东西又混了。装完之后为了让动态链接器能找到这些库需要加一个配置文件到/etc/ld.so.conf.d/echo /usr/local/apr/lib /etc/ld.so.conf.d/apr.conf ldconfig这一步不做后面 svn 启动会报error while loading shared libraries: libapr-1.so.0。ldconfig会刷新缓存让新路径生效。验证方法是ldconfig -p | grep apr能看到/usr/local/apr/lib下的库就算成功。3.3 sqlite 的版本陷阱这个必须单独拎出来说因为它坑过太多人。SVN 1.7 之后工作副本的元数据从.svn/entries文件换成了.svn/wc.db这个 SQLite 数据库。所以 SVN 对 SQLite 有强依赖。问题是SVN 自带一个内嵌的 sqlite amalgamation编译时默认会优先用它而不是系统里的sqlite-devel。带来的后果是你系统里可能装着 sqlite 3.7.x但 SVN 编出来用的是它内嵌的另一个版本。表面上看没问题直到你用某些工具比如一些 IDE 的 SVN 插件、或者自己写的脚本直接读wc.db发现版本不兼容数据库打不开。解决办法是在 configure 时显式加--with-sqlite/usr强制让它用系统的 sqlite。当然前提是你sqlite-devel已经装好了。验证方式是编译完之后执行svn --version --verbose输出里会列出- using SQLite 3.x.x对比一下是不是你系统里那个版本。如果你嫌麻烦也可以用默认的内嵌版本功能上没问题只是在跟第三方工具协作时多一层不确定性。我个人倾向指定系统库因为出问题时至少能通过yum info sqlite确认版本。4. 核心编译参数的逐项拆解4.1 configure 参数不是越多越好每个都要有理由很多人从网上抄一段 configure 参数长长一串自己都不知道每个是干嘛的。我这边给的参数集是精简过的每一项都有明确目的你按需增减。./configure \ --prefix/usr/local/subversion \ --with-apr/usr/local/apr \ --with-apr-util/usr/local/apr \ --with-sqlite/usr \ --with-apxs/usr/bin/apxs \ --with-ssl \ --enable-shared \ --disable-static \ --without-javahl逐项解释--prefix/usr/local/subversion指定安装根目录。我习惯单独建一个目录而不是直接/usr/local这样卸载的时候rm -rf一个目录就干净了不会跟/usr/local/bin下其他软件混在一起。--with-apr和--with-apr-util指向前一步编译的 apr 路径保证库一致。--with-sqlite/usr强制用系统 sqlite理由上面讲过了。--with-apxs/usr/bin/apxs是关键项。apxs 是 Apache 的扩展工具SVN 用它来编译 mod_dav_svn 模块。指定了这个路径编译过程会去读 Apache 的配置拿到正确的头文件位置和模块目录编出来的.so就能直接被 Apache 加载。如果你机器上没装 httpd-develapxs 不存在这一项会失败所以编译前先yum install -y httpd httpd-devel。--with-ssl启用 HTTPS 支持访问https://开头的仓库必需。它依赖openssl-devel没装的话 configure 会报OpenSSL not found。--enable-shared --disable-static生成动态库而不是静态库。动态库体积小多个程序可以共享升级也方便。静态库除了少数嵌入场景基本用不上。--without-javahl跳过 Java 绑定。JavaHL 是给 Java 程序通过 JNI 调用 SVN 用的编译它需要 JDK 和 SWIG链条很长。除非你有 Java 应用需要嵌入 SVN 客户端否则一律跳过能省十几分钟编译时间和一堆依赖。提示如果你只想要客户端、不要服务端和 Apache 集成可以把--with-apxs去掉加--without-apache。这样编译更快产物也更简洁。但注意 svnserve 服务端还是会编出来它是独立于 Apache 的。4.2 参数给错时的典型报错对照configure 阶段的报错信息有时候很绕我整理了实际遇到过的几种对着看能少走弯路。报错关键字真实原因处理方式cannot find APR--with-apr路径给错或 apr 没装确认/usr/local/apr/bin/apr-1-config存在且可执行APR-util not found同上或 apr-util 编译时没指对 apr重编 apr-util--with-apr必须是正确路径OpenSSL not found缺openssl-devel或 pkg-config 找不到装包后确认openssl version正常必要时加--with-openssl/usrsqlite3 not found缺sqlite-devel或--with-sqlite路径错装包检查/usr/include/sqlite3.h是否存在apxs: not found缺httpd-develyum install -y httpd-devel确认/usr/bin/apxs存在expat.h not found缺expat-devel装包它的头文件在/usr/include/expat.h这个表建议截图存着。我印象最深的一次是 apr-util 编译时--with-apr给了一个不存在的目录configure 居然不报错而是默默回退到去找系统 apr编译出来的 apr-util 跟新 apr 不匹配到 SVN configure 阶段才报invalid apr version往回倒查了好几层才找到根源。所以依赖编译阶段就要验证产物别等到最后一步。具体怎么验证 apr 编译对不对装完之后执行/usr/local/apr/bin/apr-1-config --version /usr/local/apr/bin/apr-1-config --prefix两个输出对得上/usr/local/apr就说明没问题。apr-util 同理用/usr/local/apr/bin/apu-1-config --with-apr能看到它链接的是哪个 apr。5. 从编译到验证的完整实操记录5.1 编译与安装的执行过程依赖齐了、参数定了真正跑起来就三步。但每步的输出都要留意出问题第一时间能定位。第一步下载源码。SVN 的源码包在 Apache 的归档站点上文件名形如subversion-1.14.3.tar.gz。下载完先校验sha256sum对比官方公布的哈希值别嫌麻烦压缩包损坏导致 make 阶段莫名报错的情况我遇到过一次白折腾半小时。tar -xzf subversion-1.14.3.tar.gz cd subversion-1.14.3第二步configure。把前面定好的参数贴进去执行输出会滚动很长一串检查结果。重点看结尾那几行它会列出启用了哪些特性Configured for: ... Apache module: yes Berkeley DB: no ... SSL support: yes Plaintext password storage: yes ...确认Apache module是 yes如果你需要的话SSL support是 yes。有不对的地方现在改还来得及make 之后再改就得make clean重来。第三步make make install。编译过程视机器性能而定单核大约 5~8 分钟。编译期间会有一些 warning大多是代码风格提示不影响结果不用管。真正要警惕的是 error一旦出现会立即终止。装完之后把新版本的 bin 目录加进 PATHecho export PATH/usr/local/subversion/bin:$PATH /etc/profile.d/subversion.sh source /etc/profile.d/subversion.sh用/etc/profile.d/而不是直接改~/.bashrc是为了让所有用户都能用上新命令。写进去之后新开的 shell 自动生效已经打开的 shell 需要 source 一下。5.2 验证清单从版本号到实际提交装完不等于能用我习惯跑一套验证清单五项过关才算真装好了。# 1. 版本号 svn --version --verbose # 2. 确认链接的库路径重点看 apr 和 sqlite ldd /usr/local/subversion/bin/svn | grep -E apr|sqlite|ssl # 3. 服务端版本 svnserve --version # 4. Apache 模块是否装到位 ls -l /usr/lib64/httpd/modules/mod_dav_svn.so # 5. 取模块的依赖是否齐全 ldd /usr/lib64/httpd/modules/mod_dav_svn.so第 2 步的输出最能说明问题。如果libapr-1.so.0指向的是/usr/local/apr/lib/下的说明库链接正确如果指向/usr/lib64/那说明它用的还是系统 apr前面指定--with-apr可能没生效得回头查。第 5 步也容易出问题。mod_dav_svn.so 依赖很多库ldd如果输出里有not foundApache 加载这个模块时会直接失败。常见的是libsvn_*.so找不到原因是/usr/local/subversion/lib不在链接器的搜索路径里。解决办法是把它也加进ld.so.conf.decho /usr/local/subversion/lib /etc/ld.so.conf.d/subversion.conf ldconfig全部验证通过后最实在的一步是实际建个仓库、提交一次验证端到端能跑通mkdir -p /data/svn/myrepo svnadmin create /data/svn/myrepo svn co file:///data/svn/myrepo /tmp/wc cd /tmp/wc echo test readme.txt svn add readme.txt svn ci -m init commit --username admin如果这一步能成功说明客户端、服务端、库文件全部就位。5.3 跟 Apache 集成时的配置要点要让 SVN 通过 HTTP 对外提供服务需要三个 moduledav_module、dav_svn_module、authz_svn_module。在 Apache 的配置目录下建一个文件比如/etc/httpd/conf.d/svn.confLoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so Location /svn DAV svn SVNParentPath /data/svn SVNListParentPath On AuthType Basic AuthName Subversion Repository AuthUserFile /etc/svn-auth-file Require valid-user /Location这里有个细节LoadModule dav_module可能会跟 Apache 默认配置里的重复报already loaded。解决方式是在 httpd.conf 里找到原有的那行或者用IfModule !dav_module包一层。实际部署时我一般先 grep 一遍/etc/httpd/下所有的 LoadModule确认没有重复。用户认证文件用 htpasswd 生成htpasswd -cm /etc/svn-auth-file admin htpasswd -m /etc/svn-auth-file dev01-c只在第一次创建时加后面再加用户千万别带-c否则会把文件覆盖掉前面的用户全没了。这个错我见过不止一次属于典型的粗心翻车。配置改完先httpd -t检查语法通过再systemctl reload httpd。如果 reload 失败systemctl status httpd看错误或者直接看/var/log/httpd/error_log模块加载失败的详细原因都在里面。6. 踩过的坑与排查实录6.1 动态库找不到的三类表现编译安装最集中的问题就是运行时报找不到动态库表现有三种处理方式略有不同。第一种svn命令直接报error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file。这是 SVN 自己的库没被找到因为--prefix装到了/usr/local/subversion而这个路径不在默认搜索范围内。处理就是前面说的加ld.so.conf.d配置然后ldconfig。第二种svn能跑但执行某个操作比如 https 访问时报libssl.so相关错误。这是因为它链接的 SSL 库版本跟运行环境不一致。用ldd查具体是哪个库确认路径后再针对性处理。第三种Apache 加载 mod_dav_svn 时报undefined symbol: svn_repos_xxx。这说明模块编译时链接的 SVN 库版本和运行时加载的版本不一致。多半是系统里还残留着旧版 SVN 的库文件加载时串了。用find / -name libsvn_repos*找一遍把旧版本的删掉或者挪走。这三种情况的共同点是编译期和运行期的库路径必须一致。所以我前面强调 apr 和 sqlite 都显式指定路径就是为了减少这类不一致。6.2 Apache 启动失败的排查顺序Apache 起不来错误日志一般写得比较清楚但原因可能藏在好几层。我的排查顺序是这样的先看systemctl status httpd它会给出退出码和最直接的错误行。如果是AH00526: Syntax error那就是配置文件语法问题httpd -t会告诉你在第几行。如果是Cannot load modules/mod_dav_svn.so往下看。接着ldd /usr/lib64/httpd/modules/mod_dav_svn.so | grep not found有输出说明依赖库缺失缺什么补什么。然后确认模块文件本身存在且权限正确ls -l看一下一般是root:root 755。最后看是不是模块重复加载grep -r dav_svn_module /etc/httpd/搜一遍如果两个文件都写了 LoadModule注释掉一个。这个顺序的逻辑是从粗到细先排除语法和文件层面的低级问题再查依赖这种深层问题。按这个顺序走大部分启动失败十分钟内能定位。6.3 常见问题速查表现象可能原因快速处理svn: command not foundPATH 没生效source /etc/profile.d/subversion.sh或绝对路径调用svn --version显示的还是旧版PATH 顺序问题旧路径在前检查echo $PATH把新路径移到前面svnadmin create报权限错误目标目录属主不对chown -R apache:apache /data/svnHTTP 模式或对应运行用户提交时提示Authorization failedauthz 配置或 htpasswd 文件问题确认用户名密码、检查AuthUserFile路径和权限644中文提交信息乱码终端编码或仓库编码设置确认LANG为 UTF-8仓库默认按 UTF-8 存储yum报Cannot find a valid baseurl官方源已下线挂载 ISO 做本地源或换 vault 归档地址编译时make卡住不动内存不足多核并行编译撑爆改用make -j2或单线程make6.4 两条不太常见但很值得记的经验第一条不要在同一台机器上同时保留新旧两套 SVN 的 Apache 模块。我试过让新旧并存想着切换方便结果 Apache 配置怎么写都只能加载其中一个因为模块名相同先加载的生效。后来干脆放弃并存服务端只保留一套客户端才允许多版本共存。第二条升级前先用svnadmin hotcopy备份仓库。虽然 SVN 的仓库格式向后兼容做得不错新版能直接读旧版仓库但反过来不行。一旦升级到新版开始写入再用旧版svnadmin操作就可能出问题。hotcopy是原子性复制整个仓库目录比cp -r更安全因为它处理了锁文件和临时文件的情况。备份命令svnadmin hotcopy /data/svn/myrepo /backup/svn/myrepo-$(date %F)这个操作不需要停服务跑完再把新版指过去是最稳妥的升级姿势。我在一次跨版本升级里就是因为没做这步新版写入了新格式的 revision props回滚时旧版读不懂最后只能从更早的一次备份恢复丢了两天的提交记录。这个教训值得每个人都记一下。7. Perl 绑定与可选组件的取舍7.1 Perl 绑定到底要不要装configure 默认会尝试编译 Perl 绑定因为它找不到就会跳过所以很多人没注意过它的存在。但如果你机器上有 Perl 开发环境它会默默编出来然后在你make install时往 Perl 的 site_perl 目录里塞一堆模块。这件事本身不坏坏在版本管理混乱。系统自带的 Perl 模块目录由 rpm 管理你手工装进去的模块会跟后续的yum update产生冲突。所以我的建议是明确决定要还是不要用参数说清楚别让它自己判断。要的话加--with-swig前提是装了swig包。它的作用是给 Perl、Python 等语言生成绑定代码。不要的话加--without-swig编译会干净很多速度也快。如果你确实需要用脚本批量操作 SVN比如自动导出某个版本、批量打 tag那 Perl 绑定SVN::Client或者 Python 绑定svn模块都挺方便。但这种场景用svn命令行配合 shell 脚本也能做而且更直观、更容易调试。我个人倾向不装绑定需要自动化就用命令行包一层出错时看日志也直观。7.2 Berkeley DB 和 FSFS 的选择SVN 支持两种仓库后端Berkeley DB 和 FSFS。老版本时代有过争论现在没什么悬念了——一律用 FSFS也就是svnadmin create的默认行为不需要任何额外操作。Berkeley DB 的问题在于它是嵌入式数据库需要独占文件锁一旦进程异常退出留下锁文件仓库就锁死了得手工清理。而且它对文件系统的依赖比较微妙NFS 上跑基本等于找罪受。FSFS 是纯文件存储每个 revision 一个文件好处是跨文件系统兼容性好、备份简单直接拷目录、并发读写更稳。configure 时如果不想编 Berkeley DB 支持加--without-berkeley-db。默认它可能会检测系统里的 db4 库然后启用了编出来体积大一些还多一层依赖。显式关掉更清爽。7.3 装完之后做一次精简清理make install之后源码目录会留下编译中间文件占几百 MB 空间。确认安装无误后可以直接删掉cd /path/to/source make clean如果连源码都不打算留rm -rf整个目录也行。但建议保留源码包和 configure 参数记录因为后续如果要在同环境再装一台照着参数重跑一遍就行不用重新回忆当时怎么配的。我习惯把 configure 那行命令写进一个build.sh脚本存档下次直接改版本号执行。另外/usr/local/subversion目录下有不少运行时用不到的文件比如include/头文件、share/文档如果机器磁盘紧张可以删但不建议——留着它们以后要编译依赖 SVN 库的第三方程序比如某些 IDE 的 SVN 插件要自己编时直接就能用省得再装一遍开发包。
