Databricks工程师从外部视角评Anthropic的Scion与Mononoke

最近，Anthropic 写了一篇博客文章，介绍他们新的集中式版本控制系统 Scion。作为在 Databricks 源码控制团队工作的人——我们有一个巨大的 monorepo，并且正在探索不同的方案——我觉得在这里分享我的看法可能会有用。 （例行免责声明：本文仅代表我个人观点，不代表我雇主的立场。） 我建议先读一下 Anthropic 的那篇文章，再继续往下读。 你可能还想预先读一下 Rain Paharia 的《Anthropic 的 Scion 深受 Mononoke 启发》以及后续的《再谈 Anthropic 的 Scion 抄袭 Mononoke》。 在深入细节之前，先让你了解一下我的背景可能会有帮助。 如果你对此不感兴趣，可以直接跳到技术评论部分。 我从未在 Facebook 工作过，但我最喜欢的 tech talk 之一是 Durham Goode 在 Git Merge 2017 上的《Scaling Mercurial at Facebook》。Goode 是 Facebook 源码控制团队中任职时间最长、资历最深的成员。（来源） 这个演讲涵盖了服务端和客户端两方面许多有趣的內容。服务端方面，涉及的话题包括通过服务端 rebase（pushrebase）解决推送竞争、使用可扩展的对象存储来存储提交、将各种源码控制查询移到服务端等等。客户端方面，提到了 smartlog 以及其他 CLI 命令，用于更轻松地操作历史（相比 Git 中的 rebase）。 然而，比演讲的技术内容（这些内容本身也很有趣！）更重要的，这些年来一直留在我心里的，是 Goode 的语气和措辞中所体现出的对用户的深切关怀。没有声音的力量，这有点难以传达，你应该去看看那个演讲！但以下一些引述可以体现这一点： 在谈到 hg smartlog 时：hg smartlog 为你提供一个聚焦的视图，展示你的分支以及它们与开发主干的关系。 我知道如果你知道咒语的话，Git 也能产生这种 UI，但关键不在于它能做到；而在于它成为了他们源码控制环境的默认视图。力量正来源于此：让用户真正直观地使用源码控制并理解这些概念，而无需阅读 man page。 在谈到 hg absorb 时：hg absorb 会自动神奇地识别出一个栈中正确的提交，把修复 squash 进去，并相应地重写历史。这让处理堆叠的变更变得更容易。 这正是我们需要为用户发明的那类 UI：符合他们的意图，并尽最大努力去实现，而不需要用户理解他们必须做的一切。这有点魔法，但是一种非常干净的魔法。我认为很多用户体验都能从这种方法中受益。 如果你想在 Mercurial 中撤销一次 amend 或撤销提交的某些部分，你只需运行 unamend 和 uncommit。你不必理解 reflog；你不必读个博士才能理解 reset。它就是能工作，这让用户有信心他们可以从错误中恢复。这是我们能做的最重要的事情之一：提供让用户对自己所做的事情有信心的用户体验。 在用户体验方面，我们作为源码控制社区需要更好地构建可访问、直观的 UI，让新手用户也能成为高级用户。我刚才谈的一切，就是我们在 Facebook 为我们的用户尝试做到的事情。如果 Git 社区能做到这一点，大量使用 Git 的用户就有可能为整整一代用户重新定义生产力。 这些年来，这些工作流的可能性一直萦绕在我脑海中，而我继续使用着 Git。我尝试在 git CLI 之上构建自己的封装来做一些这样的事情，但我无法让性能变得合理，因为所有东西都一直在 shell 调用 git，而我对 Git 内部机制的理解也不够深入，无法做得更好。 我最终坚持使用原版 Git，直到 Waleed Khan 创建了 git-branchless，支持 smartlog、内存中 rebase、undo 等功能。Waleed 曾在 Facebook 从事开发工具工作，后来在 Twitter 做过与版本控制相关的工作。我热切地采用了它。我也大量使用了 Stephen Jung 的 git-absorb。即使在今天，git absorb 的 README 开头部分仍引用 Mozilla 邮件列表中提到的 hg absorb 作为关键灵感来源。 最后，今年早些时候（2026 年），我在几次尝试放弃之后，基本上切换到了使用 jj。jj 由 Martin von Zweigbergk 创建，他之前为 Git 做过贡献，后来加入 Google，为 monorepo 开发他们的内部 Mercurial 客户端。来源：《Mercurial at Google》（2023）。 所以，尽管我整个职业生涯几乎只使用 Git，但在某种程度上我受惠于 Goode 以及众多其他贡献者在 Mercurial 上的工作。 我已经谈了一些我个人对版本控制工具的使用。让我简要描述一下我做过的与版本控制相关的工作。 从 2021 年底到 2025 年底，我在 Sourcegraph 从事代码索引和导航工作。其中最后两年，我更多地从事用 Go 编写的后端工作，代码导航与版本控制耦合在一起。这是因为代码导航数据几乎可以为任何提交上传。 在这段时间里，反复出现的故障来源之一，是镜像到 Postgres 中的提交图结构的（非）增量更新——这么做是为了能够高效计算哪些代码导航数据（存储在 Postgres 中）在哪个提交处是“可见”的。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）