Anthropic 重构源码管理：日均合并 30000 次背后的 Scion 系统
Anthropic 的这篇 《Redesigning source control at Anthropic》 很值得一看： https://t.co/Ah6MIcHT74 它们遇到的问题是： 5 ...
Anthropic 自己的工程博客，讲他们每天 3 万次合并、100G 仓库怎么撑住的，Scion 的客户端-服务器设计思路很开眼界。
Anthropic 在工程博客中介绍了自研版本控制系统 Scion 的设计思路。由于 5 月日均合并约 2500 次，到 9 月已超过每天 30000 次，100 G 的 monorepo 每天仅 CI 就要做约 2500 万次 checkout，Git 方案难以支撑。Scion 不是 Git 的替代品，而是针对超大 monorepo 和大量 Agent 写代码的场景：客户端-服务器不对称设计，服务器承担重负载，客户端只维护有限的对象缓存和工作副本。数据水平分散在多台机器上，单机无需存完整仓库，所有查询通过 API 暴露，许多 CI 和工具甚至不需要本地仓库。
Anthropic 的这篇 《Redesigning source control at Anthropic》 很值得一看： https://t.co/Ah6MIcHT74 它们遇到的问题是： 5 ...
Anthropic 的这篇 《Redesigning source control at Anthropic》 很值得一看： anthropic.com/engineering/re… 它们遇到的问题是： 5 月平均每天合并约 2 500 次，到 9 月已超过每天 30000 次 单仓库 monorepo 规模太大，有 100 G ，每天仅 CI 就要做约 2500 万次 checkout，流量非常大 所以重新设计了 Scion，不是 Git 的替代，适合超大 monorepo + 大量 Agent 写代码的场景 客户端不用自己存完整仓库 客户端-服务器不对称设计，服务器干重活，客户端维护有限对象缓存，工作副本等等 支持水平扩展，数据分散存在多台机器上，没有任何一台机器需要存下完整仓库。封装了完整的一个源码控制服务，所有查询都通过 API 暴露，很多 CI/工具甚至不需要本地仓库 可以收藏好好看看 💬 2 🔄 0 ❤️ 3 👀 395 📊 3 ⚡
