Anthropic Reinvents Source Control

[erek]

“After several months of model prompting and five months of migration, the result is a homemade version control system called Scion, a monorepo scheme that sounds a bit like Subversion, Apache's centralized version control system. [...] Scion has been designed to meet the needs of AI agents, so the client leaves much of the work to the server; the source control queries are exposed via API so internal tools can respond without needing a local repo, and there's less synchronization but more need for server speed.

"In Scion, the unit of work is a 'changeset,' an entry in a write-ahead log," Anthropic explains. "A changeset stores most of what you'd expect from a commit in git. But where a git commit stores a pointer to the tree, a changeset stores a list of the files that changed relative to its first parent, along with content-addressed pointers to the compressed file contents in blob storage." [...] Anthropic says its bespoke system isn't right for general use. There will be no open source release. Nonetheless, the company contends that its own code scaling problems will become commonplace in other organizations over the next few months, so it wanted to share its approach -- having ample funding to pay for writing custom infrastructure tools.“

Source: https://developers.slashdot.org/sto...-control-as-claude-floods-the-world-with-code

 

[erek]

“After several months of model prompting and five months of migration, the result is a homemade version control system called Scion, a monorepo scheme that sounds a bit like Subversion, Apache's centralized version control system. [...] Scion has been designed to meet the needs of AI agents, so the client leaves much of the work to the server; the source control queries are exposed via API so internal tools can respond without needing a local repo, and there's less synchronization but more need for server speed.

"In Scion, the unit of work is a 'changeset,' an entry in a write-ahead log," Anthropic explains. "A changeset stores most of what you'd expect from a commit in git. But where a git commit stores a pointer to the tree, a changeset stores a list of the files that changed relative to its first parent, along with content-addressed pointers to the compressed file contents in blob storage." [...] Anthropic says its bespoke system isn't right for general use. There will be no open source release. Nonetheless, the company contends that its own code scaling problems will become commonplace in other organizations over the next few months, so it wanted to share its approach -- having ample funding to pay for writing custom infrastructure tools.“

Source: https://developers.slashdot.org/sto...-control-as-claude-floods-the-world-with-code

Direct from and more targeted from Anthropic

https://www.anthropic.com/engineering/redesigning-source-control

 

[Nobu]

Could be more efficient for storage in some situations, maybe with a single branch. With multiple branches and different teams working concurrently, I think it would be less efficient.

 

[erek]

Could be more efficient for storage in some situations, maybe with a single branch. With multiple branches and different teams working concurrently, I think it would be less efficient.

isn’t it about agents and not people teams

 

[Nobu]

isn’t it about agents and not people teams

Yes, but the concept is similar. The main difference is they may have enough memory and capacity to communicate with each other and decide on one solution before commiting it to the repo, which may or may not be what you want, however that might mitigate my concern.

 

[erek]

Yes, but the concept is similar. The main difference is they may have enough memory and capacity to communicate with each other and decide on one solution before commiting it to the repo, which may or may not be what you want, however that might mitigate my concern.

they just need to be machine native

in fact maybe even the premise of this L”L”M, emphasis on language is a fallacy and pointlessly ineffective and inefficient

i know these agents were able to invent far more robust and efficient and effective methods of communication by inventing new native languages

 

[LukeTbk]

Could be more efficient for storage in some situations, maybe with a single branch. With multiple branches and different teams working concurrently, I think it would be less efficient.

Hard to see how it could be less efficiant storage wise (and bandwith), this is from the ground up made for extreme high-concurency workload with millions of daily checkouts on their server and by the need to be efficient for that situation. This is built like google/meta modern system to have very lightweight changeset, branching is almost free.

Git tend (there is way around), build around the concept every client will have a complete local copy of the repo (and of all its history), exploding the storage use (with many benefit from it), while this is making as sparse as possible checkout to minimize bandwith and storage need, keeping things server side.

There is no single branch source control (or it is not a source control system), there is mono repo or multi repo focused system.... mono repo use case make git specially less efficiant storage wise I would think, if you have 100,000 agents split in 50 different teams working on different things, easier to not have all of the repo copied if you are multi-repo.