聊聊鏡像 WordPress SVN 存儲庫的那些事

haozi

2024.09.20

甲辰龍年八月十八

154 次瀏覽

基礎設施, 開發, 生態

SVN, WP-China-Yes

一、準備鏡像 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 服務器開始提供已同步鏡像的訪問服務。