一、准备镜像 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 更新版本之前,插件库的同步暂无法继续。
总结
我自 7 月中旬开始镜像 WordPress SVN 存储库,直到目前 9 月下旬仍未能全部完成且无法给出预计完成时间。
我在此过程中遇到了很多问题,搜索了不知道多少篇文章,不少文章甚至有 10 年以上的历史,可见目前 SVN 的使用率之低。
项目莫用 SVN,老老实实 Git。
文章评论