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

2024-9-27 17:57| 发布者: 镖师| 查看: 23512| 评论: 0

摘要: 一、准备镜像 SVN从 7 月下旬开始，随着文派新服务器的到位，我便着手将 WordPress 的四个主要存储库（themes 、 plugins 、 core 、 i18n）镜像同步到国内。 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 服务器开始提供已同步镜像的访问服务。

三、签出速度缓慢

随着同步工作的推进，另一个问题逐渐暴露出来——签出的速度极为缓慢。对主题库进行一次签出操作需要超过 1 小时，而未来插件库的签出时间预计是主题库的 10 倍。

这一问题的根源在于 SVN 在执行签出时需要扫描整个存储库的内容。目前，我还没有找到有效的优化手段，只能通过减少签出的频率来暂时缓解此问题。

顺便提一句，虽然 Git 也存在类似问题，但相对而言，其影响要小得多。

四、问题深入研究

9 月初，我再次遇到了之前的报错，但这次的情况有所不同。错误的提交包含大量文件，且该插件依然在活跃维护，因此不再适合使用之前的假提交方法绕过问题的提交。

于是，我决定深入研究该问题的根源。首先，我向 SVN 社区发送了询问邮件，社区建议更新 SVN 到最新版本进行测试。显然我无法让 WordPress.org 更新他们的 SVN 版本，只能自行在本地进行实验。

我创建一个新的 SVN 存储库并进行深入研究，最终发现了一个属于 SVN 本身的漏洞（或者说是 Bug）。目前此问题已反馈给 SVN 社区，等待他们的进一步确认。

在他们正式修复问题且 WordPress.org 更新版本之前，插件库的同步暂无法继续。