伦敦Mercurial冲刺回顾

# 回顾伦敦冲刺活动 来源：https://mercurial-scm.org/news/2026/0005-london-sprint-recap ## 回顾伦敦冲刺活动\# (https://mercurial-scm.org/news/2026/0005-london-sprint-recap#recapping-the-london-sprint) 冲刺活动已经结束！ 感谢Jane Street (https://www.janestreet.com/)的慷慨接待，我们每天聚集了不到20人，成功讨论并处理了众多主题，包括午休期间关于苹果和橙子杂交基因学的引人入胜讨论。 本次冲刺由Pierre-Yves David和Raphaël Gomès（两人均为Octobus (https://octobus.net/)工作的Mercurial维护者）以及来自Jane Street的Arun Kulshreshtha发起并组织。 一张伦敦夜景图 ## 第一天 — 3月27日星期三\# (https://mercurial-scm.org/news/2026/0005-london-sprint-recap#day-1-wednesday-27th) 第一天，大家开始着手处理那些要么长期以来想做、要么在即兴讨论中激发出的任务。这非常符合第一天的重点：引导临时贡献者并推进项目整体维护。 如果将三天窗口内提交的所有可见变更都算上，我们收到了一些bug修复（#1965 (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1965)、#1968 (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1968)、#1969 (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1969)、#1970 (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1970)、#1971 (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1971)、#1976 (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1976)）、一些文档（#1967 (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1967)、#1975 (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1975)、poulpe#82 (https://foss.heptapod.net/octobus/poulpe/-/merge_requests/82)）和网站改进（hg-website#31 (https://foss.heptapod.net/mercurial/hg-website/-/merge_requests/31)）、一个用于从DAG创建合成仓库的新调试命令（#1973 (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1973)），以及一些较大型工作上的良好进展（这些工作一直未得到足够关注：#1974 (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1974)、#1966 (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1966)、ci-images#66 (https://foss.heptapod.net/mercurial/ci-images/-/merge_requests/66)）。我们还与从美国远程接入的Matt Harbison制定了一个计划，以修复Windows控制台编码弃用问题。 在Mercurial之外但与生态系统紧密相关的项目也取得了进展。Manuel Jacob帮助为hg-git (https://foss.heptapod.net/mercurial/hg-git)的技术债务制定了计划，而Georges Racinet则处理了Heptapod的18.10.4 (https://foss.heptapod.net/heptapod/heptapod/-/work_items/2687)和18.11.4 (https://foss.heptapod.net/heptapod/heptapod/-/work_items/2690)版本发布，同时致力于使Heptapod符合GitLab定义的“云原生”（heptapod#1647 (https://foss.heptapod.net/heptapod/heptapod/-/work_items/1647)）。 最后，对于那些没有忙于上述工作或熟悉Mercurial新功能的人来说，是时候开始更高级的讨论了。这些讨论在冲刺活动的大部分剩余时间里持续进行……这就引出了第二天和第三天！ ## 第二天和第三天 — 3月28日星期四和3月29日星期五\# (https://mercurial-scm.org/news/2026/0005-london-sprint-recap#day-2-and-3-thursday-28th-and-friday-29th) 第二天和第三天的议程是让每个人都了解Mercurial最新、当前和未来的发展，并讨论更大版本控制生态系统的概念。以下是我们能记得的一些较大型讨论。 ### 为Mercurial打造虚拟文件系统\# (https://mercurial-scm.org/news/2026/0005-london-sprint-recap#a-virtual-file-system-for-mercurial) 随着仓库变得越来越大，文件系统的开销在磁盘使用和速度方面变得越来越明显。即使是快速的Rust并行实现的`hg update`，对于大型工作副本也可能需要数秒，其中内核写入和inode创建开销是减速的核心因素。 众所周知，微软或Meta等科技巨头已经使用虚拟文件系统来应对这种规模问题并改善开发者体验，是时候让Mercurial拥有自己基于FOSS、完全集成的VFS了。 这项工作的上游开发已于今年早些时候开始。第一个基于FUSE的实验性只读本地版本已与覆盖文件系统结合供真实用户使用，以支持写入操作。这使得新工作副本在最坏情况下的首次交互时间从超过20秒缩短到不到2秒，而正常操作的性能开销仅为10-20%。 在冲刺期间，讨论主要集中在VFS的下一步规划上：更快的更新、在`hg status`和`hg update`中的无缝支持，以及一个集成的写入层。 ### Heptapod，我们友好的GitLab分支\# (https://mercurial-scm.org/news/2026/0005-london-sprint-recap#heptapod-our-friendly-gitlab-fork) Heptapod (https://heptapod.net/)是Mercurial在FOSS社区和专业用户中保持相关性的重要方式。其维护者Georges Racinet在刚刚跟上最新GitLab发布后，就当前状态和未来做了简短介绍。 此次讨论帮助澄清了关于Heptapod的一些误解，修复了一些小的用户问题，并推动了`hg-git`方面的工作。最后，还确定了将Heptapod升级到Mercurial 7.2的一些阻碍因素，并将很快处理。 ### 扩展废弃标记交换与束缓存\# (https://mercurial-scm.org/news/2026/0005-london-sprint-recap#scaling-obsmarker-exchange-and-bundle-caching) Florian Horn、Laurent Bulteau和Pierre-Yves David向其他与会者介绍并讨论了正在上游化的新进展。我们即将推出一套算法和格式，能够在交换废弃标记和改善束缓存方面实现显著的性能和存储改进。 虽然数学建模已经进行了很长时间，但我们终于能够开始上游实现，当这些功能可用时，我们很可能会另发文详细说明整个主题。 ### 一等冲突\# (https://mercurial-scm.org/news/2026/0005-london-sprint-recap#first-class-conflicts) 一旦你可以同时做多件事，就会遇到冲突：它们是版本控制中不可避免的一部分。冲突是一种歧义，许多版本控制系统既没有给你一个好的模型，也没有给你一个好的界面来帮助你处理它们。 Pijul (https://pijul.org/)（Darcs (https://darcs.net/)的精神继承者）是我们所知唯一一个具有冲突数学模型的活跃版本控制系统。 对于我们的用户来说，这个模型可以看作是Mercurial分支模型的扩展：分支上的多个头是分布式分支模型中事情同时发生的自然结果，而冲突则是分布式版本控制系统中事情同时发生的自然结果。 为什么我们对文件变更的建模方式应该与分支不同？事实证明，这个模型与现实世界的接触并非没有麻烦，还有很多事情需要解决。Pijul的创建者和维护者Pierre-Étienne Meunier非常愿意合作。 当然，最近Jujutsu (https://docs.jj-vcs.dev/latest)VCS变得非常流行，它以其独特风格的一等冲突而闻名。一些用户似乎从中受益匪浅，我们无疑可以从它覆盖的用例中学到一些东西。尽管如此，仍然需要一个更通用和完整的模型，因为这个方法存在边缘情况。在处理分布式安全可变历史（Mercurial独有的核心功能）时，冲突处理尤其棘手。 为此，许多人在冲刺期间聚集在一起，讨论如何将一等冲突引入Mercurial以及其他工具（如Git或JJ）。来自GitButler (https://gitbutler.com/)的Caleb Owens已经在一篇小文章 (https://cto.je/tech/should-badmerge-conflict)中写下了一些想法！ 讨论涵盖了许多问题：我们如何正式定义一些核心概念？什么是变更？什么是合并？什么是冲突？每种主要模型（合并状态（Git、Mercurial、Jujutsu）或合并补丁（Pijul））的优缺点是什么？在“状态”模型中进行带多个基的N路合并实际上意味着什么？为什么历史重写（尤其是变基）对“补丁”模型是一个挑战？ Florian最终从基本原理重新发明了Pijul模型，谁知道不同的数学家会想到相同的想法呢？虽然几个小时的讨论没有神奇地产生完美的解决方案，但它帮助参与者共享知识，并从新的角度审视这组问题。 一张伦敦夜景图 ### 规范化且可组合的历史分片\# (https://mercurial-scm.org/news/2026/0005-london-sprint-recap#normalized-and-composable-history-sharding) 早在2018年，Google就将他们的`narrow`扩展上游化，该扩展允许克隆只获取文件历史的一部分。它已经被很好地利用，但如果没有Google的基础设施，它一直非常脆弱，并且需要大量绕过问题的工作。 在7.2版本周期中，我们开始为这种半中心化工作流实现一个新模型：shapes。Shape在服务器端配置，用于定义一组路径，供窄服务器的客户端考虑。而且，它贯穿整个历史，与仓库头中这些文件的状态（例如，已删除）无关。 相比旧系统，存储shapes的优势在于： - 我们可以为常见模式定义clonebundles - 我们可以嵌套并通常组合包含和排除 - 我们可以为等效模式生成指纹 - 我们可以要求服务器和客户端就模式达成一致 - 客户端会感知到服务器的变化，从而使其模式失效 - 可以在存储shapes之上构建可靠的权限系统 - 一些遗留问题（例如CLI解析）将得到解决 这次冲刺帮助一些用户明确了概念和可能性，其中一些人似乎热心赞助部分工作以促进其企业使用。 ### Evolution：安全可变分布式历史\# (https://mercurial-scm.org/news/2026/0005-london-sprint-recap#evolution-safe-mutable-distributed-history) Mercurial的Changeset Evolution概念已经存在了一段时间，它是Mercurial在完全分布式设置中能够安全、简单地协作处理草稿历史的基础。 在冲刺期间，Caleb Owens介绍了GitButler如何处理这些协作问题，以及他们如何尝试扩展Git的数据模型以跟踪更多信息来支持这些用例。 Git当前的数据模型带来了一些挑战：内容模型是CRDT (https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type)，但与Mercurial不同，其分支模型不是，因此处理影响分支的分布式变更变得复杂。这导致GitButler从一开始就采用相当中心化的方法，并带有约束性的同步阶段。这些清晰的同步障碍为检测分布式历史编辑的内在问题并提供一个解决它们的UX提供了机会。另一方面，Mercurial的数据模型可以表示更广泛的历史编辑信息，同时保持其完整的CDRT (https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type)属性。这可以表达更广泛的状态，而无需在同步时解决这些问题。虽然我们认为Mercurial更丰富的模型允许更灵活和强大的工作流，但GitButler在UX方面的工作非常有趣，每种方法都需要互相学习。 说到用户体验，我们还讨论了在历史编辑过程中急切地变基变更集的缺点，以及一些变基无法正确还原，会“静默”丢弃一些潜在关键变更的问题。 一场更广泛的变更集Evolution用户圆桌讨论让他们表达了在Mercurial中当前体验的喜好与不足。最后，我们讨论了如何为Heptapod适配GitLab的marge-bot (https://gitlab.com/marge-org/marge-bot)：这次讨论的结果已经在某个地方投入生产，源代码应该很快会公开。 ### Git兼容性（拥抱、扩展、消灭）\# (https://mercurial-scm.org/news/2026/0005-london-sprint-recap#git-compatibility-embrace-extend-extinguish) Git在人气竞赛中获胜并稳居通用版本控制使用榜首已不是秘密。长期以来，一直有工具可以在Mercurial中使用Git仓库 (https://hg-git.github.io/)和反之亦然 (https://github.com/glandium/git-cinnabar)，但两者都没有在任一VCS的核心中得到支持。 代表Git世界的Caleb Owens和代表Mercurial世界的Raphaël Gomès讨论了Mercurial成为优秀Git服务器这一非常现实的可能性，它建立在许多正在进行的项目之上。这个想法在上一次格勒诺布尔小范围冲刺（由Pierre Augier组织）中被提及，并且与Patrick Steinhardt进行了数月的讨论。 更具体地说，Mercurial的扩展能力加上正确的工作，可以使其透明地使用Git的线协议，并为克隆和获取带来无与伦比的性能。 另外，一个Mercurial仓库可以轻松地为一个简单的用例（IDE、Shell提示、AI代理等）暴露一个假的Git仓库，使用类似于上面详述的VFS方法。 修复双向Git支持的普遍问题似乎不值得努力，但支持90%的用例已经可以使Mercurial作为未来客户端和服务器端工具极具相关性。 ### Hyperlog，一种新的强大存储格式\# (https://mercurial-scm.org/news/2026/0005-london-sprint-recap#the-hyperlog-a-new-powerful-storage-format) Revlog是所有用户数据的基础存储格式，自项目开始以来一直如此。在短短1年的revlog-v0时期之后，revlog的版本1已经陪伴我们20多年，出人意料地扩展到了数千万个修订版本和数百万个文件，这在一定程度上要归功于非常显著但渐进的改进，如`generaldelta`、`zstd`、`sparserevlog`以及许多运行时优化。 即便如此，这种格式已经显示出弱点很长时间，无法真正引领我们进入下一个规模或用户体验的飞跃。我们已经在为revlog的新版本（V2）工作了几年，为了方便说服管理层，我们昵称它为`Hyperlog`。虽然这个名字最初是个玩笑，但它感觉非常俗气，是V1原名`RevlogNG`的合格继承者。 以下是冲刺期间讨论的非详尽功能列表： - 可变索引条目 - 多个索引和数据块/文件