Original Summary

Anthropic recently described Scion, the version control system they built because git stopped scaling for their monorepo: tens of thousands of merges a day, mostly from agents, and millions of CI checkouts. The post explains the design but not the code, so I started an open-source implementation in Rust. Repo: https://github.com/bnsd55/open-scion Original post: https://www.anthropic.com/engineering/redesigning-source-control Independent project, not affiliated with Anthropic. The idea The server keeps history and makes the commits. A client reads only the files it needs over gRPC and never clones. A commit ("changeset") stores only the paths that changed against its first parent. Files and trees are content-addressed using BLAKE3 and never change. Landing is a server-side rebase: if none of your paths changed on main since your base, the server puts your change on top and moves main with one compare-and-swap. Two agents touching different files never conflict and never pull. What works today Proof of concept, one machine: One-way git import, checked commit by commit against git scn cat scn ls scn log scn commit scn land JSON output for agents 200 concurrent agents landed 10,000 changes with none lost or duplicated, at about 200 lands/s Disk flushes are the current limit; group commit is in progress A 23,871-commit git repo imports in about 50 seconds A frozen, fuzzed byte format CI on Linux and macOS What's next Cache tiers and sparse checkout — the fast-read half of the design — then virtual checkout, blame, and permissions. All planned work is tracked in the issues. I'd especially like feedback on the land path — a per-ref path index keyed by generation number — and on the durability design. Issues and PRs are welcome.   submitted by   /u/Winter-Frame8644 [link]   [comments]

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：Reddit · SideProject
  • 发布时间：2026/10/14 15:26:54