Apache安装SVN site-1.8.22插件全流程：版本匹配、编译避坑与403排查

简介：这是一份面向 Eclipse/MyEclipse 开发者的 SVN 版本控制插件资源包，站点版本为 site-1.8.22，适合需要在 IDE 中直接完成代码提交、更新、历史查看与冲突解决的 Java 工程师。包内共 30 个文件，主体为 27 个 jar 插件组件，同时包含 xml 配置源、html 帮助入口以及一份针对 MyEclipse 10 的安装说明文档，压缩包整体仅 16.9MB，便于快速部署。当前已有 939 人学习下载。文件按 features、plugins 目录组织，结构清晰，用户可借助安装说明一步步添加更新源并启用 SVN 支持，减少手工配置成本。该版本基于 Subversion 1.8.x 稳定系列，兼顾 SVNKit 与 JavaHL 两种客户端适配，覆盖从代码检出、提交更新到分支合并、差异对比等常用场景，适合团队协作中需要统一版本管理流程的开发环境搭建。

1. 装 SVN 插件 site-1.8.22 这件事，看着简单但容易卡住

做了这么多年运维，SVN 服务端我装过不少回，但每次遇到要在 Apache 上挂 SVN 插件这种活，心里还是会多打几个问号。常见的场景是：SVN 服务已经跑起来了，或者公司要统一代码版本管理，需要在 Web 端同步暴露一个访问入口，这时候就得给 SVN 配一个 site 插件包。site-1.8.22 是很多入门教程里推荐的版本，但真正装起来你会发现，版本号对不上、依赖少装一个、apache 配置写错位置，都可能让整个服务直接起不来，或者起来之后怎么访问都是 403。这不是玄学，是 SVN 插件和 Apache、SVN 主版本三者之间互相绑定的问题。这篇笔记我按自己实际走过的流程写，把环境准备、编译安装、Apache 挂载、权限配置和常见的翻车现场都记录下来，给正在配这套东西的开发者一个能照着走的参考。

2. 装之前先认清环境：版本匹配比什么都重要

2.1 为什么 1.8.22 这个版本这么挑环境

site 插件本质上是一组 Apache 的 DSO 模块，它要跟 Apache 的 DAV 模块、SVN 的核心库在同一套编译链路上协同工作。1.8.22 这个版本号对应的是 SVN 1.8.x 分支，它编译时依赖的 SVN 库头文件、Apache 的 APR（Apache Portable Runtime）版本，都有明确的对应关系。很多人一上来直接用系统自带的 svn 命令测试，发现能用，就觉得环境没问题，结果编译插件时报出一堆 "cannot find -lsvn_subr-1" 之类的链接错误，就是这个环节出了岔子。

我一般会在动手之前把三样东西列成一张表：操作系统版本、Apache 版本、SVN 核心库版本。这里说的 SVN 核心库，不是 svn 客户端命令行，而是通过svn --version看到的 libsvn 版本。site-1.8.22 要求 libsvn 在 1.8.x，如果系统里装的是 1.9 或者 1.7，编译时会有很大概率链接到错位的符号表，即使编译过了，运行到一半也可能崩溃。

提示：安装之前先把这三者的版本用一条命令打出来，记进文本文件里。出了故障想查版本差异时，你一定会感谢当时的这个习惯。

2.2 系统依赖和基础软件包准备

以我常用的 CentOS 7 和 Ubuntu 20.04 为例，因为 site 插件要从源码编译，所以需要提前把编译工具链和开发包准备好。CentOS 上要用yum groupinstall "Development Tools"拉起 gcc、make 等工具，Ubuntu 上则用build-essential包。只装编译工具还不够，下面这几个开发头文件包是最容易漏掉的。

# CentOS 7 / Rocky 8 yum install -y httpd httpd-devel subversion-devel apr-devel apr-util-devel # 或者 Ubuntu 20.04 / 22.04 apt install -y apache2-dev subversion libapache2-mod-svn libapr1-dev libaprutil1-dev

注意我写的是subversion-devel或者subversion加配套的-dev包，光有subversion客户端二进制是不够的。site 插件编译时需要/usr/include/subversion-1目录下的头文件，比如svn_repos.h，还需要链接libsvn_repos-1.so，这些只在 devel 包里才有。另外httpd-devel或者apache2-dev提供的是apxs工具，它用来把编译出来的模块自动安装到 Apache 的模块目录并写进配置，这个工具后面在编译阶段会用到，建议提前确认apxs命令能不能执行。

2.3 下载 site-1.8.22 并校验完整性

源码包下载的地方我一般习惯找 SVN 官方镜像站或者代码托管平台上维护者发布的 release 归档，如果是从第三方站点下的，建议顺手校验一下 MD5。site-1.8.22 的源码包解压之后应该包含configure、Makefile.in、mod_site.c这样的文件，如果你拿到的包里没有configure文件，说明下载到的不是完整的源码发布版，直接换一个源。

wget https://example.com/site-1.8.22.tar.gz md5sum site-1.8.22.tar.gz tar -xzf site-1.8.22.tar.gz cd site-1.8.22 ls -l configure Makefile.in mod_site.c

这里我故意用example.com占位，是因为每个人能访问的镜像源不一样，但md5sum这个动作对所有来源都适用。校验文件完整性看起来很老土，但确实能避免解压到一半报 "tar: Unexpected EOF" 这种问题。解压之后先确认目录里有configure和Makefile.in，再做下一步，不然到编译阶段才反应过来文件损坏，浪费时间。

3. 编译安装与挂载：一步步把模块装进 Apache

3.1 configure 参数怎么给才算对

site-1.8.22 这个包配置的时候有几个关键参数决定它能不能正确找到 SVN 和 Apache 的库。我个人最常用的是--with-apxs和--with-svn这两个。--with-apxs要指向 Apache 的 apxs 工具绝对路径，--with-svn则指向 SVN 的安装前缀，如果你是系统包安装的，一般不用指，它会通过 pkg-config 自己找到，但如果你是自己编译过一份 SVN 放在了非标准目录，就必须显式写路径。

./configure \ --with-apxs=/usr/bin/apxs \ --with-svn=/usr \ --with-apr-config=/usr/bin/apr-1-config \ --with-apu-config=/usr/bin/apu-1-config make

在这一步我最常看到的错误是configure: error: subversion libraries not found，这通常不是你 SVN 没装，而是--with-svn给的前缀不对，SVN 的库文件实际放在/usr/lib或/usr/lib64，但头文件在/usr/include/subversion-1，configure 脚本会默认去前缀/lib和前缀/include底下找，如果你的 SVN 是发行版自带，直接--with-svn=/usr通常不会错。编译过完会产生一个mod_site.so文件，它会被 apxs 自动复制到 Apache 的模块目录，同时把一行 LoadModule 配置追加到 httpd.conf。

3.2 Apache 里加载模块和配置 Location 映射

模块编译完并不代表立即能用，你要在httpd.conf（Ubuntu 上是/etc/apache2/apache2.conf和mods-available/目录）里确认加载顺序。site 插件必须排在mod_dav.so和mod_dav_svn.so之后，因为它在运行时要调用 DAV 提供的钩子函数，顺序反了 Apache 直接拒绝启动。

LoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule site_module modules/mod_site.so <Location /svn> DAV svn SVNPath /opt/svn/repos AuthType Basic AuthName "SVN Site" AuthUserFile /etc/apache2/svn-auth.conf Require valid-user </Location>

SVNPath指定的是仓库目录的绝对路径，这里注意不要写成SVNParentPath，除非你打算在一个根目录下面挂多个仓库。一个常见误区是Require valid-user写成了Require user site，导致所有用户都被拒。另外AuthUserFile指向的文件要用htpasswd创建，不要直接拿文本编辑器手动写密码字段，否则登录验证百分百失败。

3.3 创建 SVN 仓库并初始化目录结构

模块加载只是搭好了框架，真正的代码仓库还得手动创建，这一步做了之后你才能通过http://服务器IP/svn访问到东西。仓库目录我习惯放在/opt/svn下面，不要放/var/www下，主要是权限规划上更干净，也不怕 Apache 用户对源码文件产生误操作。

mkdir -p /opt/svn svnadmin create /opt/svn/repos chown -R apache:apache /opt/svn/repos # Ubuntu 上用户是 www-data chmod -R g+w /opt/svn/repos

创建好的仓库会生成conf/、hooks/、db/等子目录，svnadmin create默认就是 standard 布局，不需要额外加参数。chown 这步是为了让 Apache 进程用户（apache 或 www-data）对 db 目录有写权限，否则通过 Web 端 commit 的时候会报 "Can't open file /opt/svn/repos/db/txn-current-lock: Permission denied"，权限陷阱十有八九就出现在这里。如果仓库之前已经建过，但用户不对，用chown -R批量修正一次最省事。

4. 避坑排查：我把常见的四个报错现场按现象、原因、解决的顺序拆开

4.1 configure 时提示 subversion libraries not found

这个错误我见过太多次，几乎每次在全新机器上装都会遇到。它的现象是执行./configure到中途就退出，屏幕上的最后几行输出是checking for subversion libraries... not found，后跟configure: error。初看像 SVN 没装，但svn --version明明能跑。实际原因多半是 configure 脚本只找到了 SVN 程序文件，没找到开发用的头文件，也就是/usr/include/subversion-1这个目录缺失，或者--with-svn指定到了错误的前缀。解决办法是确认安装subversion-devel包，Ubuntu 对应的是libsvn-dev，然后重新执行 configure，并且把--with-svn明确指到/usr。

4.2 Apache 启动报 undefined symbol 或 module syntax error

模块装好了，发现apachectl graceful重启时给了httpd: Syntax error on line ...: Cannot load ... into server: undefined symbol: dav_svn_split_uri。这个报错十有八九是 SVN 库版本和 site-1.8.22 期望的版本不一致，我遇到过系统自带的 libsvn 是 1.10 但插件是 1.8.22 编译出来的，符号表对不上。另一种可能是mod_dav_svn.so没加载，先检查 httpd.conf 里LoadModule dav_svn_module是否存在且在前。解决方法是统一版本，卸载自带 SVN 后按 1.8.22 对应的 SVN 1.8.x 从源码重编一遍，或者换用与 svn 版本匹配的 site 插件版本，不建议用-fPIC之类的编译参数硬绕过。

4.3 访问 /svn 返回 403

403 属于既不明显也最容易折腾人的问题。这里往往不是模块的问题，而是访问权限逻辑。我之前遇到过一次，Apache 主配置里只写了<Location /svn>，但忘了在httpd.conf里有全局的<Directory />默认拒绝规则，导致 apache 在读取/opt/svn/repos目录时被拦下来。另一个高发原因是Require valid-user写成了Require all granted，看起来差不多但一个是认证后放行，一个是完全不认证。解决办法是先加<Directory /opt/svn/repos>段，明确Require all granted给内部目录放行，然后在<Location /svn>里保留认证设置，最后记得用htpasswd -c /etc/apache2/svn-auth.conf 用户名重新生成密码文件。

4.4 通过 Web 提交时报 E170013 无法连接

出现E170013: Unable to connect to a repository at URL时，很多人第一反应是网络问题，但我要分享一个血泪经验：绝大多数情况下是 SVN 仓库被 Apache 用户锁了存储文件。检查/opt/svn/repos/db下的locks文件属主，看看是不是 root 或者别的用户创建的，chown -R apache:apache解决不了这种问题，还需要chmod -R ug+rwx /opt/svn/repos/db让组用户可写，否则即使密码正确也会被 SVN 层拒绝写入。这属于文件系统权限和 Apache 权限互相打架的坑，排查顺序务必是：先看 Apache 错误日志/var/log/httpd/error_log，再去看仓库目录属主。

5. 版本兼容性对照与配置调优

5.1 site-1.8.22 与 SVN、Apache 的兼容矩阵

装完并且验证跑通之后，有些开发者会忽略版本兼容性这个问题，但其实它才是后续维护里最容易踩雷的区域。我根据自己的部署经验整理了一个版本对照表，注意这只代表常见做法，不保证覆盖所有编译组合，写出来是让你心里有个底，部署前先拿这个做基准判断。

在实际工作中，如果系统自带 SVN 是 1.9 或 1.10，但业务非要 site-1.8.22，那么正确的做法不是硬着头皮编译，而是先降级或并行安装 SVN 1.8 的开发库版本，然后在./configure时通过CPPFLAGS和LDFLAGS指定到那个自定义的安装前缀，比如--with-svn=/usr/local/svn1.8，这样插件链接到的符号表才不会跟系统库混淆。反过来，如果现有仓库已经使用了 SVN 1.10 的格式，硬降级可能打不开仓库，这种时候就要好好掂量是仓库文件更重要，还是兼容这个旧插件更重要。

5.2 编译参数调优：静态链接还是动态依赖

site-1.8.22 默认编译出来的mod_site.so动态依赖 libsvn 系列的共享库，这也意味着运行时只要系统里 libsvn 版本一变，模块就可能因为缺符号或者符号不兼容而罢工。我一般会给这里多加一个编译选项，把关键 SVN 库静态拉进来，减少对系统库的依赖性，这在多套环境之间搬运同一个模块时特别好用。

./configure \ --with-apxs=/usr/bin/apxs \ --with-svn=/usr \ --with-apr-config=/usr/bin/apr-1-config \ --with-apu-config=/usr/bin/apu-1-config \ LDFLAGS="-Wl,-Bstatic -lsvn_repos-1 -lsvn_fs-1 -Wl,-Bdynamic"

-Wl,-Bstatic会让链接器优先以静态方式链接后面列出的libsvn_repos-1.a和libsvn_fs-1.a，-Wl,-Bdynamic再切回动态模式，避免把 glibc 等基础库也静态进来。这样编译出来的mod_site.so虽然体积变大，但换到同架构另一台机器上的存活率会高很多。不过有一点要注意，静态链接之后，如果你的仓库数据格式和运行环境里加载的其他 SVN 模块不一致，远程调用时还可能出兼容问题，所以这个方法更适合单机独立跑的站点，不适合大规模集群分发。

5.3 性能参数与连接池调整

site 插件本身没有太多性能参数，它主要依赖 Apache 的 worker 配置和 SVN 的访问缓存机制。我做过的调优里有两点收益最高：第一，给 Apache 开启KeepAlive On并设置KeepAliveTimeout 5，客户端重复 checkout 多个文件时，不需要频繁握手；第二，在httpd.conf里给/svn这个 Location 关闭不必要的日志，降低磁盘 IO 压力。

<Location /svn> DAV svn SVNPath /opt/svn/repos AuthType Basic AuthName "SVN Site" AuthUserFile /etc/apache2/svn-auth.conf Require valid-user </Location>

注意这里没有列出SVNAutoversioning On，因为自动版本化在很多团队里并不是刚需，反而会让非预期的版本提交混入仓库。如果你的使用场景是纯代码托管，SVN 本身已经自带版本管理，不必开启自动版本化。另外，Apache 的MaxRequestWorkers要根据服务器内存调整，一般按每个 worker 占用 10MB 估算，2G 内存的机器我通常给到 200，再高容易内存溢出，这一点用ps -ylC httpd实时观察一下负载再定也可以。

6. 装完怎么验证跑通：从 checkout 到权限的完整自检

模块装好、Apache 也成功启动之后，不要急着宣告大功告成，建议按下面的五个步骤走一遍验证流程，每步都是模拟真实用户的操作路径，这样可以趁早发现配置上的隐患。

第一步是本地命令行验证仓库本身没问题：

svn co --username testuser http://localhost/svn/testproj /tmp/testproj

如果这台服务器上有多个仓库，URL 路径要按<Location>中定义的路径走。这一步能通过，就说明网络层、模块加载、认证这三个关键环节都正常。本地测试通过之后，再用另一台机器或本机其他 IP 访问一次，避免 apache 把 localhost 和真实 IP 的访问规则区分对待。

第二步是验证权限边界。用两个不同账号，一个加入Require valid-user允许的用户文件里，一个不加入，分别尝试访问同一个 URL，确认不被允许的账号无法 checkout，这样才能保证代码不会被未授权的人拿走。

第三步是实际提交一次变更。在/tmp/testproj里新增一个文件，执行svn add和svn commit -m "test commit"，提交成功后再执行svn log -l 5，确认最新的提交记录和提交者信息都正确，这一步能同时检验 Apache 用户对仓库目录的写权限是否到位。

第四步看错误日志。tail -f /var/log/httpd/error_log或 Ubuntu 上的/var/log/apache2/error.log，观察刚才几次操作有没有产生 WARN 级别以上的记录。毫无输出的 clean log 是理想状态，出现Permission denied就要回头看仓库的文件属主，出现认证失败要检查AuthUserFile的路径和密码文件权限。

第五步比较推荐做一次重启测试。执行apachectl graceful优雅重启，再执行一次 checkout，确保模块在重启后仍然能稳定加载，这一步能提前发现模块加载顺序或者动态库丢失的问题。

这套全流程走完，我要多说一句，从那以后我每次给 SVN 装类似插件，都会强迫自己把「环境版本记录 → 编译参数快照 → 权限清单」这三样东西写成文档放进部署目录，产线上出问题的时候翻文档比现场猜快太多了。希望这份安装笔记能帮你少踩几个坑，顺利把 site-1.8.22 跑起来。

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