Emacs 与 Bzr 的坎坷往事

# Emacs Bzr saga：史上最长的版本控制之争 来源: https://thanosapollo.org/posts/bzr-saga/ 既然今天没什么有趣的书可读，也没什么好看的电影，我决定在网上挖掘一些最引人入胜的内容。我本来去读了 Linux 内核邮件列表，但那里的讨论似乎有点“少儿不宜”（18+），于是我转而阅读了相对文明的 `emacs-devel` 邮件列表。 对于不熟悉的人来说，`emacs-devel` 是 GNU Emacs 的主要开发讨论列表——在这里做出设计决策，审查补丁，偶尔还会有人花费 200 条消息来争论版本控制软件。这就是关于最后那件事的故事。 ## 2008 年：“这个问题已经讨论完毕，决定已下” 2008 年 3 月，Emacs 正准备从 CVS（没错，就是 CVS）迁移到更“现代”的工具。当时的两个竞争者是 Git 和 Bazaar。 - Git，由 Linus Torvalds 为 Linux 内核创建。 - Bazaar 是一个 GNU 项目，*由 Canonical 维护*。 `emacs-devel` 上爆发了一个包含 236 条消息的长线程。人们测试了这两款工具的性能。结果并不含蓄。Andreas Schwab (https://yhetil.org/emacs-devel/[email protected]/) 作为核心开发者之一，报告了他的第一印象： > 我的第一印象是 bzr 很慢，慢到完全不可用。为什么一个简单的 `bzr log` 启动都要花超过一分钟？相比之下，即使 `cvs log` 需要向服务器请求日志，它的响应也是瞬间完成的。 David Kastrup 也觉得这令人费解： > 我发现这很令人惊讶：“git log”几乎是瞬间完成的，而且 git 在此过程中还会重新计算代码片段的历史记录。相比之下，用户在复制、移动或重命名文件时必须告知 Bazaar，因此它应该能够立即提供这些信息。 实际的数据对比： - `git log | head -1` 耗时 0.012 秒。同样的命令在 Bazaar 上耗时 21.5 秒。 - 提交单个文件的更改：Git 耗时 0.08 秒，Bazaar 耗时 17 秒。 基准测试还在继续。Stefan Monnier (https://yhetil.org/emacs-devel/[email protected]/)，Emacs 的主要维护者，设定了较低的门槛： > 我不在乎 Bzr 比 Git 慢还是快，但为了切换到 Bzr，我们需要它“足够快”。目前它还不够快。至少 `bzr diff` 不应该花费几秒以上的时间。 与此同时，Jonathan Lange (https://yhetil.org/emacs-devel/[email protected]/)，Canonical 的一名真正的 Bazaar 开发者，正在该线程中进行技术支持。 他推荐的初始检出工作流程： > 一种更好的初始下载方式如下： > $ wget http://bzr.notengoamigos.org/emacs.tar.gz > $ tar xzf emacs.tar.gz > $ bzr init-repo emacs-bzr > $ cd emacs-bzr > $ bzr branch ../emacs trunk > $ cd trunk > $ bzr pull –remember http://bzr.notengoamigos.org/emacs/trunk/ 请将其与 `git clone` 进行比较！ 终于，有人提出了显而易见的问题： > 致 Emacs 维护者和决策者：还需要什么更多信息才能说服大家 Bzr 目前不是合适的工具？ Richard Stallman (RMS) 的回复： > 这个决定不是针对当下的，而是一个长期的决定。因此，最好等待几个月让 Bzr 开发者改进它，而不是做出某些可能难以逆转的“临时”决定。 为了以防有人没明白他的意思，他在另一条消息中 (https://yhetil.org/emacs-devel/[email protected]/) 补充道： > 这个问题已经讨论完毕，决定已下。我们将使用 GNU Bzr，因为它是一个 GNU 软件包。 当有人指出这种政治性决定“抹杀了所有技术论点”时，RMS 回复道 (https://yhetil.org/emacs-devel/[email protected]/)： > GNU 软件包应相互支持的原则有助于使整个 GNU 系统运行得更好。 有人顺理成章地追问：“为什么我们不能只是把 Git 纳入 GNU 系统？” RMS： > 我们可以把它包含在 GNU 系统中，但它的开发者不太可能愿意让它成为一个 GNU 软件包。 公平地说，RMS 这里有一个真实的理念。如果 GNU 项目不使用自己的工具，这会传递出一个信号，即这些工具不够好，从而破坏自给自足的自由软件生态系统的整个理念。他几十年来一直秉持这一论点，并且在许多其他情况下这对项目大有裨益。问题不在于原则本身。问题在于 Bazaar 无法承受这一原则的重量。 236 条消息的线程、基准测试、Canonical 员工的变通方案……这些都未能改变结果。这是一个政治决定，而政治立场已经既定。 ## 2008-2012 年：漫长的尾巴 世界其他地区已经转向了 Git。GitHub 于 2008 年推出并迅速爆发式增长。与此同时，Emacs 贡献者不得不学习 Bazaar，一种他们在其他地方都不使用的工具，仅仅为了提交补丁。 类似“请帮我把卡住的 bzr 弄好”和“无法 bzr emacs 仓库（可能是 bzr 内存泄漏）”的讨论变得司空见惯。 **然后，在 2012 年，Canonical 裁掉了 Bazaar 开发团队。** ## 2013 年 2013 年 3 月，也就是 Bazaar 开发停止一年后，John Wiegley 发布了 (https://yhetil.org/emacs-devel/[email protected]/T/#u) 大家一直想说的话： > 我们经常辩论 Git 与 Bazaar 的优点，以及 GNU 项目应该使用哪一个进行 Emacs 开发。我认为现在是重新审视这一决定的合适时机。我再次提出这个问题的主要原因是 Bazaar 的开发实际上已经停滞。他们的错误追踪系统中存在许多重大错误，其中一些影响 Emacs 开发的错误（例如 ELPA 仓库）已经被忽视多年。所以，致 Emacs 的无可争议的沙皇 Richard：我们现在，恳请，能切换到 Git 吗？ 随后跟了 200 条消息。 RMS 的第一次回应： > 维护者说他在修复一些错误，我昨天还让他修复 ELPA 分支的错误。我想给他合理的时间来做这件事。 这个错误已经存在了 1.5 年。Dmitry Gutov 指出了这一点 (https://yhetil.org/emacs-devel/[email protected]/)： > 这不是很晚了吗？这个错误已经存在 1.5 年了。他之前不知道吗？ 随后 RMS 亮出了他的底牌 (https://yhetil.org/emacs-devel/[email protected]/)： > 我正在试图确定 Bzr 是否得到有效维护。我宁愿得到一个“是”的答案，而不是“否”的答案。 这在公开场合说是一件非常诚实的事情。他并没有隐藏他的偏好。他真心相信 GNU 项目相互支持的原则，并希望现实情况能配合这一原则。 Joakim Verona (https://yhetil.org/emacs-devel/[email protected]/)，一名长期的 Bazaar 用户和 Emacs 贡献者，描述了实际情况： > 我尽力做一个建设性的用户，但我遇到了许多技术困难。当我试图寻找我注意到的问题的解决方案时，我发现： > - bzr 社区非常乐于助人。这是好的。 > - 有许多众所周知的错误。也有许多针对这些错误的知名补丁，其中一些由 Emacs 开发者提供。它们从未进入上游。我说“从未”，意思是几年都未进入。这是不好的。 RMS 回复道 (https://yhetil.org/emacs-devel/[email protected]/)： > 我没有时间阅读 Bzr 邮件列表。或者任何开发邮件列表。我唯一订阅的此类列表就是这一个。让我去阅读 Bzr 列表上的东西，就像让我飞到月球一样不现实。 当被问及 Bazaar 的用户是否应该对 Bazaar 是否得到充分维护拥有发言权时： > 当我必须决定一个维护者是否做得足够好或者需要被替换时，我会关注我收到的任何相关信息。然而，让用户在决定中拥有“发言权”似乎不合适，所以我不这样做。 Karl Fogel，一位开源开发老兵（《Producing Open Source Software》(https://producingoss.com/) 的作者，也是最初的 Subversion 开发者之一），在该线程中提出了最尖锐的批评： > 好吧，事实上，你没有足够的时间密切关注 Bzr 的开发，以便有能力判断它是否仍然是 Emacs 的一个好选择。这没关系——没有人有时间做所有重要的事情，而且你做很多其他重要的事情。但既然这样，为什么你认为你仍然有时间和脑力带宽来做好这个决定？为什么不基于你不再有时间做好这项评估的理由，将其委托给 Emacs 维护者？ 他指出，询问一个人关于一个错误的情况并不能作为项目健康状况的代理，并且考虑到他的时间限制，线程中的其他人已经做了比他更彻底的研究。 RMS 的回复： > 因为这里涉及的不仅仅是 Emacs。 只有一行字，但这是他世界观的核心。如果旗舰 GNU 项目放弃一个 GNU 工具，这会向其他所有 GNU 软件包发出什么信号？他在利害关系上并没有错。他在工具选择上错了。 Karl 再次施压： > 你应该要么投入足够的时间来评估 Bzr 的维护状态以获得可靠的答案，要么委托给能这么做的人。相反，你要求维护者依赖你的调查……但你明显没有时间做好这项工作。这是对每个人时间的糟糕利用。 RMS： > 我已经有一个如何进行此事的计划，并且我正在执行它。 没有细节。没有时间线。没有委托。相信我。 与此同时，Stefan Monnier 在整个 200 条消息的线程中只发布了一条实质性的消息： > 就像我没有反对 Richard 选择 Bazaar 一样，我也不太在乎我们是继续使用 Bazaar 还是切换到 Git、Monotone、Darcs、Mercurial、OpenCM、Fossil，随你便。我现在唯一关心的是从 Bazaar 中移出 'elpa' 分支，因为 Bazaar 无法正确处理它。 Leo Liu 总结了大家的想法： > 正如您可能意识到的那样，大多数 GNU 项目并不使用 BZR。虽然帮助 BZR 修复错误可能对 BZR 有益，但从整体上看对 GNU 却是损失。志愿者花费他们的空闲时间在 GNU 项目上，如果 20% 的时间花在解决 BZR 问题上，其成本之高以至于会阻碍人们加入。为了 GNU 的最大利益，离开 BZR 似乎是唯一明智的选择。 该线程在没有明确解决方案的情况下结束。RMS 有一个计划。他正在实施它。这 200 条消息没有产生决定，但它们确实让社区的立场变得毫无疑义。 ## 2013 年：ELPA 分支崩溃 同年晚些时候，Stefan 采取了实际措施，为随后发生的一切奠定了基础。Bazaar 上的 ELPA 分支坏了，这是一个导致检出的 bug，且已无人为其修复。Stefan 将其移至 Git，他的公告展示了那种在此过程中一直维持 Emacs 开发运行的谨慎领导力： > 我对这一变化不太满意，因为这意味着我们将使用两种不同的工具（'elpa' 用 Git，'trunk' 用 Bzr），但我真的看不到其他出路。我不希望这成为关于 Git 与 Bzr 优点/缺陷的讨论，这也不是讨论在 'trunk' 上使用 Git 的场合。 他完全清楚每个人都在想：“如果 Git 对 ELPA 来说足够好，为什么不对 trunk 也如此？”并提前堵住了这个话题。一次解决一个问题。 ## 2014 年：ESR 按下按钮 到 2014 年 8 月，Eric S. Raymond 已经准备好了转换脚本。 他一直在默默地工作 (https://yhetil.org/emacs-devel/[email protected]/)： > 你们没有听到太多关于它的消息，因为艰苦的工作已经完成。我的脚本准备就绪，只需要提前大约八小时通知即可按下按钮。 实际的迁移发生在 2014 年 11 月。11 月 13 日，ESR 发布了一条 (https://yhetil.org/emacs-devel/[email protected]/) 七个单词的消息： > 提交已开放。开始吧。 有些人甚至将其描述为英雄行为 (https://yhetil.org/emacs-devel/[email protected]/)。 六年的争论，2008 年线程中的 236 条消息，2013 年线程中的 200 条消息，Stefan 多年的默默维护，无数“帮我把卡住的 bzr 弄好”的请求，一个死掉的版本控制系统，最终结束于这七个单词。 ## 事后 迁移后的几天是富有教育意义的。一半的核心贡献者从未使用过 Git： - “这是 Git 帮助邮件列表 (https://yhetil.org/emacs-devel/[email protected]/)” - “git pull 因合并冲突失败。这怎么可能发生？” - “给我们这些普通人一个简单的 git 工作流程” - “需要帮助调整工作流程以适应 git” - “关于 Git 的好书” - “来自 git pull 的晦涩错误/警告/信息消息”（124 条消息） 这些人是多年来一直在开发世界上最重要的文本编辑器之一的人，却在询问基本的 Git 问题，因为他们在世界其他地区都已向前迈进时，被困在了 Bazaar 上。 真是个 bzr 传奇！不管怎样，比我今晚能看的任何电影都精彩。