---
canonical: https://meta.cyberforums.com/t/wordpress-svn/71
webpage: https://wpcy.com/community/t/71-wordpress-svn
language: zh-Hans
---

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

> 文派叶子支持论坛的只读副本，本页不能回复。
> 讨论原文：https://meta.cyberforums.com/t/wordpress-svn/71
> 网页版：https://wpcy.com/community/t/71-wordpress-svn

## 1 · system

- 发布时间：2025年2月17日 13:49

文章首发于：			聊聊镜像 WordPress SVN 存储库的那些事 - 文派茶馆 WP TEA


一、准备镜像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。