Just because you might find this interesting: Scion deviates significantly in this regard in order to deal with merges; coming from git, we land code to our main branch via merge so it's a common occurrence. We do…
Very little, overall. This system was actually built incrementally over several months and did not start out as a full VCS -- it started as a read-only service that ingested data from our Git repo to take pressure off…
I don't use HN often, so I made an account for this purpose that would make it clear who I was in relation to the article.
Hi! I am the original author of the blog post and wanted to clear the air a bit here. We credited Sapling because that's how Meta itself externally refers to the entire system, including the Mononoke server, and we…
The point explicitly isn't that you should vibe-code your own VCS. There are a lot of ideas here that would be directly applicable to git, for example, and we are working to share the learnings with the right companies…
If you're referring to this part: > This does mean that concurrent changes can conflict, but Claude can typically fix these conflicts faster than humans can even identify them. We never allow textual conflicts, but…
Of course! The point is that it is a non-starter to operate this way but git doesn't hold your hand to do the right thing here. Everyone probably lands on approximately similar solutions with varying degrees of…
That's true, but logistically speaking the way that git wants data to exist on disk makes it very, very hard to do the kinds of things we needed to do given how many nodes we have that need source code and how quickly…
Building all of the systems to train and serve our models, internal tools and infrastructure, (lots and lots of) research, our product and API surfaces, and more. We have a lot of problems that we can solve with code…
It sounds like it would be simple, but there are a lot of logistical issues with making git happy with this in practice. Repacking things for repo maintenance, for example, but there are many other problems.
The changeset and tree manifests are still a Merkle tree in the ways that matter (i.e., it's all immutable, content-addressed, verifiable if you were so inclined), the client just doesn't need the entire thing locally.
There actually was lot more hand-writing of the code back then! Or, at least, only moderately assisted by Claude with a lot of human-still-typing-things-in-an-editor. The ability to delegate larger chunks of code to…
A monorepo gives us a really consistent tooling floor where everything more or less works in a uniform way. We've had a lot of success with it, in general, and it gives us a lot of leverage in the sense that we can make…
https://cloud.google.com/spanner, though technically any database would work if you know how to scale them. Spanner just has a few nice properties for our scale. Good call about us not defining it, I can fix that! And…
It actually scales by "going wider" and being able to do more things rather than iterating on the same code over and over again. If you can only write X amount of code per day because of some limitation (human…
The Cursor folks are doing cool work, but this is comparing apples to oranges; it works fundamentally differently and does not have a clear one-to-one mapping. Scion is solving many problems other than raw write speed…
We have a file size limit of 5MB and I aggressively pruned all binary content that really wasn't fit for source control since it compresses really poorly and can cause performance problems in git when updating a…
I agree, but most of this sits above the raw source control layer; we have a lot of this kind of context in Antique (our code review / code management platform). I hope we can share more about what's worked well for us…
Practically speaking, we could build local commit buffering for when the server is offline, but then the client needs to also learn how to do all of the things the server currently knows how to do (and would still never…
This would be us doing a shallow checkout of individual commits (not cloning the full history) if we downloaded the 25GB compressed data for whatever commit we needed multiplied by the number of jobs that check out…
One benefit of uploading things immediately is that you can launch a research job, run CI, or share code between all of your developer environments absolutely trivially. The commit hash "just works everywhere". There is…
100% handwritten!
The issue is the growth rate; we'll approach that size in a (relatively) short amount of time if it keeps up and we have to be ready. It's also self-fulfilling in a way, since Scion was so much faster, we are able to…
In a repo these large, there are a lot of tests and pipelines that need to run as this code is tested, built, and deployed. Each test shard we run in parallel needs to check out the code, for example.
> You could imagine in the future, some associated highly flexible "owner" rules/notifications where a human can specify "I want to be notified if X system has a significant design change" and that intent can be…
Just because you might find this interesting: Scion deviates significantly in this regard in order to deal with merges; coming from git, we land code to our main branch via merge so it's a common occurrence. We do…
Very little, overall. This system was actually built incrementally over several months and did not start out as a full VCS -- it started as a read-only service that ingested data from our Git repo to take pressure off…
I don't use HN often, so I made an account for this purpose that would make it clear who I was in relation to the article.
Hi! I am the original author of the blog post and wanted to clear the air a bit here. We credited Sapling because that's how Meta itself externally refers to the entire system, including the Mononoke server, and we…
The point explicitly isn't that you should vibe-code your own VCS. There are a lot of ideas here that would be directly applicable to git, for example, and we are working to share the learnings with the right companies…
If you're referring to this part: > This does mean that concurrent changes can conflict, but Claude can typically fix these conflicts faster than humans can even identify them. We never allow textual conflicts, but…
Of course! The point is that it is a non-starter to operate this way but git doesn't hold your hand to do the right thing here. Everyone probably lands on approximately similar solutions with varying degrees of…
That's true, but logistically speaking the way that git wants data to exist on disk makes it very, very hard to do the kinds of things we needed to do given how many nodes we have that need source code and how quickly…
Building all of the systems to train and serve our models, internal tools and infrastructure, (lots and lots of) research, our product and API surfaces, and more. We have a lot of problems that we can solve with code…
It sounds like it would be simple, but there are a lot of logistical issues with making git happy with this in practice. Repacking things for repo maintenance, for example, but there are many other problems.
The changeset and tree manifests are still a Merkle tree in the ways that matter (i.e., it's all immutable, content-addressed, verifiable if you were so inclined), the client just doesn't need the entire thing locally.
There actually was lot more hand-writing of the code back then! Or, at least, only moderately assisted by Claude with a lot of human-still-typing-things-in-an-editor. The ability to delegate larger chunks of code to…
A monorepo gives us a really consistent tooling floor where everything more or less works in a uniform way. We've had a lot of success with it, in general, and it gives us a lot of leverage in the sense that we can make…
https://cloud.google.com/spanner, though technically any database would work if you know how to scale them. Spanner just has a few nice properties for our scale. Good call about us not defining it, I can fix that! And…
It actually scales by "going wider" and being able to do more things rather than iterating on the same code over and over again. If you can only write X amount of code per day because of some limitation (human…
The Cursor folks are doing cool work, but this is comparing apples to oranges; it works fundamentally differently and does not have a clear one-to-one mapping. Scion is solving many problems other than raw write speed…
We have a file size limit of 5MB and I aggressively pruned all binary content that really wasn't fit for source control since it compresses really poorly and can cause performance problems in git when updating a…
I agree, but most of this sits above the raw source control layer; we have a lot of this kind of context in Antique (our code review / code management platform). I hope we can share more about what's worked well for us…
Practically speaking, we could build local commit buffering for when the server is offline, but then the client needs to also learn how to do all of the things the server currently knows how to do (and would still never…
This would be us doing a shallow checkout of individual commits (not cloning the full history) if we downloaded the 25GB compressed data for whatever commit we needed multiplied by the number of jobs that check out…
One benefit of uploading things immediately is that you can launch a research job, run CI, or share code between all of your developer environments absolutely trivially. The commit hash "just works everywhere". There is…
100% handwritten!
The issue is the growth rate; we'll approach that size in a (relatively) short amount of time if it keeps up and we have to be ready. It's also self-fulfilling in a way, since Scion was so much faster, we are able to…
In a repo these large, there are a lot of tests and pipelines that need to run as this code is tested, built, and deployed. Each test shard we run in parallel needs to check out the code, for example.
> You could imagine in the future, some associated highly flexible "owner" rules/notifications where a human can specify "I want to be notified if X system has a significant design change" and that intent can be…