聊聊镜像 WordPress SVN 存储库的那些事

一、准备镜像 SVN

从 7 月下旬开始，随着文派新服务器的到位，我便着手将 WordPress 的四个主要存储库（themes 、 plugins 、 core 、 i18n）镜像同步到国内。 WordPress 的这些存储库基于 SVN 架构，而非如今流行的 Git 。这是因为在 WordPress 诞生时，Git 尚未出现。

起初，我打算直接使用 svn checkout 命令来下载存储库内容，但很快就 pass 了。原因是 svn checkout 并不支持断点续传，且 WordPress 的存储库规模庞大，特别是插件库，其大小已达到 TB 级别。使用此方法无法稳定地将如此大量的数据从境外传输至国内。

经过一番搜索，我发现了 svnsync 命令，这个工具能够递归同步目标存储库的所有版本号，并将这些版本顺序提交到本地的空存储库，直到与目标版本号一致。 svnsync 天然支持断点续传，也便于同步后续的提交内容。

得益于 AI 的帮助，我很快写好了同步脚本，并启动了四个存储库的同步任务。然而，事情并没有这么顺利结束。同步过程中，插件库报出了错误：e175009: the xml response contains invalid xml，导致同步卡在了版本号 2231806，无法继续。

排查问题的根本原因并不是最重要的（SVN 本身存在很多历史遗留问题，WordPress 的 SVN 版本甚至是十几年前的 1.7 版），我需要尽快解决问题以恢复同步。

经过一番调查，我找到了一个可能的解决方案，灵感来自一封 14 年前的邮件记录 Subversion Dev: Re: Question on svnsync – want to quickly start from rev 800000 (haxx.se)。

最终方法是手动修改存储库的数据库文件，通过假提交的方式跳过有问题的版本号。

具体操作是使用 svnmucc -m "FIX" put FIXFILE 命令，将一个伪造文件提交到插件存储库的根目录，并手动调整版本号数据。虽然之后报出了文件不一致的错误，但这次给出的提示信息明确指出了具体的插件目录。检查后发现该插件已废弃，我手动下载了该插件的源码，并使用 svnmucc 命令提交后，问题得以继续解决。

在后续同步过程中，遇到类似问题时，我都采取了相同的方法，直到 9 月的一天。

二、搭建 SVN 服务器

在等待同步完成的同时，我也开始着手搭建自己的 SVN 服务器。经过一番研究后发现，Apache+mod_dav_svn 是唯一可行的方案。虽然过程繁琐，但对我来说，这些并不是难题。

我很快查到了编译 mod_dav_svn 模块的参数，因为很多文档已经过时，我经过反复多次调整，最终成功编译安装了所需模块。以下是使用的配置命令：

./configure --with-apxs=/www/server/apache/bin/apxs --with-apache-libexecdir=/www/server/apache/modules --with-apr=/www/server/apache --with-apr-util=/www/server/apache --with-lz4=internal --with-utf8proc=internal

需要注意的是，编译前需要安装 libserf-dev 库，否则编译后的 SVN 版本将不支持 HTTP 协议。

在完成这些准备工作后，我顺利搭建了 SVN 服务器开始提供已同步镜像的访问服务。