Anthropic 的 Scion 深受 Mononoke 启发。

Anthropic 的 Scion 深受 Mononoke 启发。
Anthropic's Scion is heavily inspired by Mononoke

原始链接: https://sunshowers.io/posts/anthropic-mononoke/

作者指责 Anthropic 在介绍新版本控制系统 Scion 时未注明先前工作。Anthropic 称 Scion 使用“派生数据”来加速 blame；作者表示，他曾在 2022 年为 Meta 的 Mononoke 描述过同样的技术。他认为这种重合超出了独立洞见的范围，尤其是 Sapling 只得到含糊的致谢，而 Mononoke 完全没有，这近乎抄袭。他觉得该文章暗示这些想法是 Claude 发明的，而 Meta 团队在近十年前研究现有技术后就已开发出它们。他并不反对 Anthropic 借鉴 Mononoke 的开源设计——分享好想法正是目的所在——但警告称，LLM 将大量索引现有设计，包括 Mononoke。既然其他模型已经识别出相似之处，注明前人就比以往更容易，也更重要。

Hacker News 的讨论围绕一篇文章展开，该文认为 Anthropic 的新源码控制系统 Scion 受 Mononoke（Meta Sapling 的服务端组件）的启发很深，并且与其高度相似。Anthropic 的公告致谢了 Sapling/Piper，但未提及 Mononoke，引发关于署名的争议。评论者对这是可接受的启发、抄袭，还是工程师重建熟悉系统各执一词。作者表示复制可以，但希望明确致谢，尤其因为 LLM 能复现先前设计；他们声称 Claude 被指向 Mononoke。其他人讨论 Git 对超大型 monorepo 的实际限制、AI 驱动的代码量、营销/IPO 形象、干净室逆向工程，以及 Anthropic 声明的可信度。一些人捍卫 Anthropic 的扩展能力；另一些人批评缺少引用、潜在的知识产权清洗，以及“氛围式构建”的基础设施。帖子还包含对 Sapling/Mercurial 的怀旧，以及对 LLM 不注明来源的担忧。总体而言，争议较少关于技术，更多关于署名、规范和对 AI 辅助工程声明的信任。

原文

Discuss on Hacker News or Lobsters.

Here is Anthropic describing (archive link) yesterday how their new version control system, Scion, uses a concept called “derived data” to make operations like blames more efficient:

A changeset records only what’s changed, so on its own, it can’t quickly answer questions like who last edited a line or which commits affected a file. To answer those, Scion builds additional data structures from the changesets, including dedicated structures for file blame and path history and skip lists for the commit graph. We call everything that isn’t directly part of the changeset “derived data,” and we compute it all through one generic mechanism. Each type of derived data is defined recursively, so its value for a changeset is computed from its values for that changeset’s parents. This mechanism has three benefits. First, we can easily add a new type of derived data when a new data structure would make some operation faster. Second, for each type, we can choose whether to compute it eagerly or defer the work, so we avoid materializing data we don’t need. And third, because the client never sees the internals of these data structures, we can optimize them without changing the client. We’ve added new types of derived data many times as the system has grown, such as new indices for performing copy detection or path-based file search. — How Anthropic describes Scion’s derived data.

Here is me, back in 2022, describing in my Oxide candidate materials how the Mononoke source control server I helped build uses a concept called “derived data” to make operations like blames more efficient:

Derived data. While Bonsai changesets work great for pushes, they work less well for things like diffs. Git diff commit1..commit2 is an O(n log n) operation where n is the number of changed files – with Bonsai changesets, you’d have to look at every single commit between commit1 and commit2 to compute the list of files changed. For a large repository this can be orders of magnitude slower (and compounds the pointer-chasing problem). To solve this, we moved the diff-friendly representation to being derived data (i.e. an index). The server creates a separate Merkle DAG with a Git-like tree/blob model, with pointers back to Bonsai changesets as required. Note that: Derived data can be computed and stored asynchronously, outside of the main critical section. The pointers between commits and trees are flipped around. With the Git data model, the text of a commit contains the hash of the root tree. With the Bonsai model, the text of the root tree contains the hash of the commit that introduced it. This gave us the ability to build out other derived indexes for whatever other operations we wanted. For example, git blame is quite slow on large git repositories, requiring a traversal of the entire repository (not just commits that touch the file). With Mononoke, we built out a blame-friendly index where each version of each file was a separate node in the Merkle DAG, with its parent set to the previous version of the file, and with pointers back to Bonsai changesets. This meant that blames became O(number of commits that touch the file) rather than O(number of commits in the repository). Over time, the team has added more indexes to handle specific use cases, and Mononoke now has 8 separate indexes. Adding a new index is a relatively cheap operation that doesn’t involve any fundamental changes to data structures. — How I described Mononoke’s derived data.

I think the level of imitation goes well beyond having similar insights^{. The fact that Sapling was only credited for “hard-won lessons”, and that Mononoke was not mentioned at all, borders on plagiarism. The post comes off as Anthropic claiming that Claude designed all this, while the reality is that our (extraordinary) team at Meta came up with many of the insights that Claude dutifully applied almost a decade later. (We looked at plenty of prior art for Mononoke and Sapling too, from Google’s SrcFS to write-ahead logs in databases.)}

I am very glad that the vision our team had back in 2017-18 was so powerful and enduring — when you go against the grain, you’re always a bit unsure if what you’re doing is genius or madness, and I think Mononoke’s design has stood the test of time. And, to be clear, I do not have a problem with Anthropic copying Mononoke’s design. (This is part of why we put out open source — to benefit humanity through the spread of good ideas.)

But as LLMs continue to assist in designing new systems, they are likely to index heavily on existing designs. Mononoke is open source and in every LLM’s training set. If you ask Opus 5.5 or GPT-6 Astra (thanks Matthew Fowle) about prior art, they both immediately point out the similarities to Mononoke.

Giving credit to those that came before us is now easier — and more important — than ever. There is no longer an excuse.

Anthropic 的 Scion 深受 Mononoke 启发。 Anthropic's Scion is heavily inspired by Mononoke

Anthropic 的 Scion 深受 Mononoke 启发。
Anthropic's Scion is heavily inspired by Mononoke