It's hard for me not to see this as Anthropic effectively doing a "git clone" with extra steps.
Uncharitable? I don't think so.
If this were about functionality, why not use Sapling/Mononoke or extend it and contribute back to the open source community? I guess that doesn't juice the IPO valuation.
There's a reason no one uses Sapling at scale besides Meta. Just because it's open source doesn't mean it's practical to deploy on your own infrastructure. Using it and contributing back to the open source community (does it have a community?) would be much more work than forking. This is not because Sapling is bad, it's very impressive tech, but it's designed to meet Meta's needs specifically. The README says directly, "Not yet supported publicly, OSS is buildable for unsupported experimentation" for two of its three components (Mononoke and EdenFS).
If Anthropic vibe-coded a million lines of improvements to Sapling and dropped them in a PR (or many) I expect the Sapling project would not be overjoyed to accept those contributions.
I don't find this defense of these lab's continued vibe stunts compelling. They certainly could behave in a way that benefits rather than strip mines. That is a choice.
I think the idea that Anthropic had seven engineers spend five months building a custom VCS as a "vibe stunt" when they could just have easily used and contributed to an existing open source solution is unnecessarily cynical, personally.
It suggests that those engineers are doing bad work. I don't think that's a well supported conclusion.
I think that last statement is a poorly supported non sequitur. Whether they are doing good or bad engineering is entirely beside the point and (again) unverifiable.
Why would you imply that the only other way they could have handled this is be a bad open source citizen with a 1M line PR? And you are the one who first used "vibe-coded" as the hypothetical alternative.
We are talking about a company who's entire business model is intellectual labor arbitrage, hoovering up the entirety of human knowledge, distilling it, and renting it back to us.
You don't have to carry their water in every post.
For me, Occam's razor says that Anthropic looked at existing VCS options and decided none of them were the right fit for what they needed.
Two years ago, adopting an open source system and helping improve it may have been the best option.
This year, with unlimited Claude credits, I would likely have made the same decision they did. Contributing to an existing project is a lot more time consuming than building from scratch (thanks to the human coordination overhead), and time is the only resource they didn't have in abundance.
You don't have to carry their water in every post.
Contributing to an existing project is a lot more time consuming than building from scratch
This is yet another false dichotomy.
And time consuming for what?
What about bug fixes, training, growing the system, understanding, long term maintenance, shared value, openness, building something that lasts? These all have virtue and value. Subverting those concerns with yet another pull of the magic slot machine lever has a cost too.
LISP programmers know the value of everything and the cost of nothing. - Alan Perlis
It's this pervasive, frenetic, short term thinking that is hollowing out the heart and soul of our industry.
But, so what if we (literally) destroy a few thousand libraries worth of books, strip mine every open source repo, and extract every ounce of unmonetized value from knowledge work of the last 4 thousand years. Saying we are obfuscating another copy operation all while claiming novelty is just "unnecessarily cynical."
A lot depends on how narrow the differences are between Sapling and Scion and what Anthropic made. Do major build changes normally land in less than 5 months? Coordination and consensus building is very slow.
How does that hypothetical justify what they did?
And how do we know the alternative was a 1M line slop PR?
No way to know that because Scion isnt open source, is it?
why not use Sapling/Mononoke or extend it and contribute back to the open source community
It's not just at that scale. There's tons of projects here by single people who "need" to make something new rather than contribute to the already existing initiative. And in those cases you know for sure that it is entirely unsustainable.
I read this post and was angry on the author's behalf. Then I learned - not from the post - that in fact one of the things Anthropic did credit is the larger system of which Mononoke is a component. This has made me much less upset with Anthropic and moderately upset with this post's author for not stating this up front. I'm willing to believe that this was omitted only because it's hard to remember that these things aren't background knowledge to everyone, rather than e.g. to make this seem like a bigger deal to readers than it would otherwise (which is the effect this omission had on me), but I think this post ought to be clearer about that.
With this context, and having re-read Anthropic's post, I don't think Anthropic behaved badly here, unless there's even more context I'm still missing. Can someone who is upset even with this context spell out in a little more detail what you think the problem is?
The fact that Sapling was only credited for “hard-won lessons”
The resemblance goes well beyond "hard-won lessons". It is a direct copy.
And yes, there is further information that isn't public that I was later made aware of. Sometimes you write to the world with the expectation that the world writes back to you, and sometimes that expectation is fulfilled.
They said "we were able to build Scion with [Piper's and Sapling's] hard-won lessons in mind". You would have liked them to say "we based Scion's design on Sapling's design"? Because to me, the former covers the latter, but if you don't read it that way I guess I can see why you'd like them to be more explicit. Still, this seems a minor faux pas at best (in the absence of the nonpublic information you allude to, which obviously I can't really update on unless you want to gesture at its shape somehow).
Since you're here, would you consider editing your post to make the connection between Sapling and Mononoke explicit so that future readers are not misled the way I was?
You would have liked them to say "we based Scion's design on Sapling's design"?
I would have liked them to say "we based the server design closely on (specifically) Mononoke's design", especially given the overlap in personnel. The reality is closer to "Claude was pointed directly to Mononoke to take its design from", though I didn't have confirmation of this before I wrote the post — reading the Anthropic post, nothing like that even remotely comes through. (It's a lot less impressive when the hard design work is already done and you copied it wholesale in five months!)
I was charitable when I assumed Claude came up with it from its training data.
Since you're here, would you consider editing your post to make the connection between Sapling and Mononoke explicit so that future readers are not misled the way I was?
I can do that tomorrow, but I want to be clear that Sapling can either mean just the user-facing client or the entire system. If you were previously on Meta's source control team and you make your way to Anthropic's source control team, I expect you to say that you were inspired by Mononoke specifically, not just Sapling, because you absolutely know the difference. And that you copied from it. (I mentioned on HN that Lore is a good example of a VCS that can say it was inspired by Sapling or Mononoke while not being a copy.)
I think this is another case where we need a term for "forking without forking". The behavior of Anthropic here is that of someone forking a project. They want the same basic implementation but they want to control the future direction. The term forking has a legacy of being tied specifically to a source control action and that doesn't quite fit. Saying Anthropic forked Mononoke would give some people the wrong impression. However the pre-DVCS impression of forking seems to apply to this and other code duplication by LLM vendors:
Forking is considered a Bad Thing—not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking.
The only thing that ever comes out of a slop generator is "slopforking"; unattributed plagiarism. In this instance, the regurgitation is so blatant that it is possible to identify one specific originating work which was heavily copied from but not cited. Most of the time connections are much hazier and more diffuse, but the output is equally dependent upon and obscurantist toward the countless "inspirations" in the training set.
Every time someone generates or uses slop they're disrespecting and devaluing the humans who created the material in that training set in exactly the same way as when Anthropic pointedly spits in the face of one identifiable project as part of their latest marketing piece. A remarkable number of LLM enthusiasts never seem to express concern about this pattern until it is their own work- or perhaps a specific creative niche they care about- being trampled upon to marginally enrich a mega-corp.
In this instance, the regurgitation is so blatant that it is possible to identify one specific originating work which was heavily copied from but not cited.
Because Anthropic, the trustworthy and upstanding organisation they are, explicitly requested exactly that. How do they call this, when a single source is chosen and a lower-capability imitation is attempted, illicit distillation? Their words not mine.
I don't think that this case illustrates your point about plagiarism by nature; it's plagiarism by request. Corporations are not limited to being bad in one way, they are not even limited to be at their worst specifically on the issue you care about most. They can be bad in multiple ways at once, and it is worse.
While I share your concerns and have made similar points in other discussions, I'm trying to point out that there is an additional social offense here that relates to the project (as in the organization of humans around a set of problems) rather than to the code (which is a product or artifact of that project).
Given that Anthropic credited Sapling, and Mononoke is a component of Sapling (the server part of it), I don't find this complaint particularly convincing.
If Anthropic hadn't credited Sapling I'd see their behavior as extremely bad form.
(I'd I was Anthropic I'd update the original announcement to credit Mononoke, too.)
Enough, Simon. You have carried enough water for these companies. This is nonsense. This is well beyond "hard-won lessons" — this is a direct copy made by (what I've been told) is an overlapping group of people. Given how contrarian the design was back then, and still is in many ways, it is basic decency to say that the data model is a direct copy (the word "ripoff" has been used).
I have since privately received information that this was done in bad faith, and that I was far too generous in my post. Does that change your beliefs?
it looks like the core concept of "derived data" was heavily inspired by Mononoke, the server component of Sapling
I want to be clear that it isn't just the concept of derived data that is inspired by Mononoke. A Scion changeset is almost exactly the same as what we in Mononoke called a Bonsai changeset. I led the design and initial implementation work for Bonsai changesets back in 2018, including writing the four canonical design documents that are still the reference. The advantages of Bonsai changesets are very non-obvious until you spend a great deal of time thinking about the problem, which I had given my years of experience on version control.
This is not surprising given the additional information I received later, which includes the fact that Claude was pointed directly at Mononoke and told to copy it. The fact that none of this is even remotely hinted at is shameful; taking an existing battle-tested (over a decade!) design and copying it in 5 months is much less impressive than coming up with a brand new design and productionizing it in 5 months.
edit to add that there are also other parts such as an API to do source control queries and mutations with that are copied from Mononoke. Those have been done elsewhere before Mononoke, too. In general it is always good to situate your work in the larger context of what came before you.
I led the design and initial implementation work for Bonsai changesets back in 2018, including writing the four canonical design documents that are still the reference. The advantages of Bonsai changesets are very non-obvious until you spend a great deal of time thinking about the problem, which I had given my years of experience on version control.
I work in public research, and I recognize this situation as "you should write a paper about this". The description that you use in your post comes from, if I understand correctly, personal documents you wrote for a job application. Curiosity question: have you / your team considered writing actual papers / public technical reports about these things? (Why not?)
I did say in the comments to Anthropic post, that they don't say enough to figure out what they took and combined from known and tried ideas.
I would say that stressing derived data (as in your main pot) does not really feel like much more convincing, as derived data at the level they describe it is just database indexing and caching, so who knows.
But the claim you make here in the comment, this one is a damnable omission on their part. What exactly goes into the changeset in Bonsai is clearly a careful optimisation for a monorepo use case (my dream DVCS for personal use would have functionality incompatible with that!), and when they closely followed that, it's a clearly more of a fork/rewrite than «hard-won lessons», and yeah, that needed to be explicitly credited to Mononoke and Bonsai changesets.
Thanks a lot, that was much more substantial to read than the first version!
Re: contrarian — as a happy Monotone (a completely different and much older Mono?o?e VCS!) user and someone who packages enough stuff to have been forced to use Darcs slightly outside the happy path, I would say that contrarianism of that approach does not impress me as contrarian, but figuring out exact details of the core design to mait the throughput goals possible is indeed a great achievement.
I wonder who will be the first to break, swallow the eventual consistence pill, and remember that both Monotone and Mercurial track branches in a way that allows multiple heads, which avoids full-linearisation requirement. I prefer Monotone's «global branch names, so you cannot avoid multiple heads» approach for small-scale workflow reasons too, but it also hits the nail on the head for a slightly catastrophic scaling-out scenario.
FWIW, I think server-side rebases with the Bonsai model allow you to have a total linear order on main very efficiently. This is what we called "push rebase" -- the original version was done within Mercurial, using files on disk and the Mercurial data model. Mononoke's contribution here was to implement push rebases efficiently using the Bonsai model, in the context of a stateless server built on top of an object store. As you've been able to tell, Bonsai changesets and efficient push rebases were carefully designed to work together and scale up (they've scaled up just fine to an order of magnitude beyond the original design parameters).
Linearity still forces one to have a mutex for updating the head position, no? Although with good design it can scale up very well (out, that's harder)
(Also rebases lie about what was tested, but fortunately nobody ever reads history to see those lies)
Yes. The goal of the Bonsai data model is to make that critical section as small, and involve as few pointer chases, as possible.
Agreed that push rebases don't detect semantic merge conflicts across files (they worked at the file and directory level). In massive monorepos this isn't a major problem though, especially because work would generally be done against the latest "warm" bookmark, which meant a bookmark for which the build system had already verified things and cached build results.
We do not have a trust relationship, so obviously I'm not going to share private correspondence with you. But the public evidence is what it is, and beyond that you'll need to take my word for it.
First they brought noise and air pollution, and increased power bills to backwater towns, but I did not complain, because I didn't live in one of those towns, and my personal convinience outweighs the externalities.
The they came for the fruits of my intellectual labor, but there was no one left to speak out about it.
How different is Mononoke from Google's Piper (and the layers on top of it, of which there are several)? Is there anyone in the world familiar with both? I feel like it should be easy for some amount of conference evolution to happen here.
pmbauer | 23 hours ago
It's hard for me not to see this as Anthropic effectively doing a "git clone" with extra steps.
Uncharitable? I don't think so.
If this were about functionality, why not use Sapling/Mononoke or extend it and contribute back to the open source community? I guess that doesn't juice the IPO valuation.
mk12 | 20 hours ago
There's a reason no one uses Sapling at scale besides Meta. Just because it's open source doesn't mean it's practical to deploy on your own infrastructure. Using it and contributing back to the open source community (does it have a community?) would be much more work than forking. This is not because Sapling is bad, it's very impressive tech, but it's designed to meet Meta's needs specifically. The README says directly, "Not yet supported publicly, OSS is buildable for unsupported experimentation" for two of its three components (Mononoke and EdenFS).
simonw | 23 hours ago
If Anthropic vibe-coded a million lines of improvements to Sapling and dropped them in a PR (or many) I expect the Sapling project would not be overjoyed to accept those contributions.
pmbauer | 23 hours ago
I don't find this defense of these lab's continued vibe stunts compelling. They certainly could behave in a way that benefits rather than strip mines. That is a choice.
simonw | 23 hours ago
I think the idea that Anthropic had seven engineers spend five months building a custom VCS as a "vibe stunt" when they could just have easily used and contributed to an existing open source solution is unnecessarily cynical, personally.
It suggests that those engineers are doing bad work. I don't think that's a well supported conclusion.
pmbauer | 23 hours ago
I think that last statement is a poorly supported non sequitur. Whether they are doing good or bad engineering is entirely beside the point and (again) unverifiable.
Why would you imply that the only other way they could have handled this is be a bad open source citizen with a 1M line PR? And you are the one who first used "vibe-coded" as the hypothetical alternative.
We are talking about a company who's entire business model is intellectual labor arbitrage, hoovering up the entirety of human knowledge, distilling it, and renting it back to us.
You don't have to carry their water in every post.
simonw | 23 hours ago
For me, Occam's razor says that Anthropic looked at existing VCS options and decided none of them were the right fit for what they needed.
Two years ago, adopting an open source system and helping improve it may have been the best option.
This year, with unlimited Claude credits, I would likely have made the same decision they did. Contributing to an existing project is a lot more time consuming than building from scratch (thanks to the human coordination overhead), and time is the only resource they didn't have in abundance.
I don't.
pmbauer | 20 hours ago
This is yet another false dichotomy.
And time consuming for what?
What about bug fixes, training, growing the system, understanding, long term maintenance, shared value, openness, building something that lasts? These all have virtue and value. Subverting those concerns with yet another pull of the magic slot machine lever has a cost too.
It's this pervasive, frenetic, short term thinking that is hollowing out the heart and soul of our industry.
But, so what if we (literally) destroy a few thousand libraries worth of books, strip mine every open source repo, and extract every ounce of unmonetized value from knowledge work of the last 4 thousand years. Saying we are obfuscating another copy operation all while claiming novelty is just "unnecessarily cynical."
hyperpape | 14 hours ago
A lot depends on how narrow the differences are between Sapling and Scion and what Anthropic made. Do major build changes normally land in less than 5 months? Coordination and consensus building is very slow.
pmbauer | 23 hours ago
How does that hypothetical justify what they did? And how do we know the alternative was a 1M line slop PR? No way to know that because Scion isnt open source, is it?
k749gtnc9l3w | 13 hours ago
Having a publically available diff, even if it's not merged, is valuable on its own.
alper | 13 hours ago
It's not just at that scale. There's tons of projects here by single people who "need" to make something new rather than contribute to the already existing initiative. And in those cases you know for sure that it is entirely unsustainable.
bakkot | 21 hours ago
I read this post and was angry on the author's behalf. Then I learned - not from the post - that in fact one of the things Anthropic did credit is the larger system of which Mononoke is a component. This has made me much less upset with Anthropic and moderately upset with this post's author for not stating this up front. I'm willing to believe that this was omitted only because it's hard to remember that these things aren't background knowledge to everyone, rather than e.g. to make this seem like a bigger deal to readers than it would otherwise (which is the effect this omission had on me), but I think this post ought to be clearer about that.
With this context, and having re-read Anthropic's post, I don't think Anthropic behaved badly here, unless there's even more context I'm still missing. Can someone who is upset even with this context spell out in a little more detail what you think the problem is?
sunshowers | 21 hours ago
From my post:
The resemblance goes well beyond "hard-won lessons". It is a direct copy.
And yes, there is further information that isn't public that I was later made aware of. Sometimes you write to the world with the expectation that the world writes back to you, and sometimes that expectation is fulfilled.
bakkot | 20 hours ago
They said "we were able to build Scion with [Piper's and Sapling's] hard-won lessons in mind". You would have liked them to say "we based Scion's design on Sapling's design"? Because to me, the former covers the latter, but if you don't read it that way I guess I can see why you'd like them to be more explicit. Still, this seems a minor faux pas at best (in the absence of the nonpublic information you allude to, which obviously I can't really update on unless you want to gesture at its shape somehow).
Since you're here, would you consider editing your post to make the connection between Sapling and Mononoke explicit so that future readers are not misled the way I was?
sunshowers | 20 hours ago
I would have liked them to say "we based the server design closely on (specifically) Mononoke's design", especially given the overlap in personnel. The reality is closer to "Claude was pointed directly to Mononoke to take its design from", though I didn't have confirmation of this before I wrote the post — reading the Anthropic post, nothing like that even remotely comes through. (It's a lot less impressive when the hard design work is already done and you copied it wholesale in five months!)
I was charitable when I assumed Claude came up with it from its training data.
sunshowers | 13 hours ago
I can do that tomorrow, but I want to be clear that Sapling can either mean just the user-facing client or the entire system. If you were previously on Meta's source control team and you make your way to Anthropic's source control team, I expect you to say that you were inspired by Mononoke specifically, not just Sapling, because you absolutely know the difference. And that you copied from it. (I mentioned on HN that Lore is a good example of a VCS that can say it was inspired by Sapling or Mononoke while not being a copy.)
dvogel | 7 hours ago
I think this is another case where we need a term for "forking without forking". The behavior of Anthropic here is that of someone forking a project. They want the same basic implementation but they want to control the future direction. The term forking has a legacy of being tied specifically to a source control action and that doesn't quite fit. Saying Anthropic forked Mononoke would give some people the wrong impression. However the pre-DVCS impression of forking seems to apply to this and other code duplication by LLM vendors:
https://en.wikipedia.org/wiki/Fork_(software_development)
I'm a terrible marketer but "slopforking" conveys an ickiness that matches how I feel when I read about these projects. Like eating gruel :)
Internet_Janitor | 6 hours ago
The only thing that ever comes out of a slop generator is "slopforking"; unattributed plagiarism. In this instance, the regurgitation is so blatant that it is possible to identify one specific originating work which was heavily copied from but not cited. Most of the time connections are much hazier and more diffuse, but the output is equally dependent upon and obscurantist toward the countless "inspirations" in the training set.
Every time someone generates or uses slop they're disrespecting and devaluing the humans who created the material in that training set in exactly the same way as when Anthropic pointedly spits in the face of one identifiable project as part of their latest marketing piece. A remarkable number of LLM enthusiasts never seem to express concern about this pattern until it is their own work- or perhaps a specific creative niche they care about- being trampled upon to marginally enrich a mega-corp.
k749gtnc9l3w | 4 hours ago
Because Anthropic, the trustworthy and upstanding organisation they are, explicitly requested exactly that. How do they call this, when a single source is chosen and a lower-capability imitation is attempted, illicit distillation? Their words not mine.
I don't think that this case illustrates your point about plagiarism by nature; it's plagiarism by request. Corporations are not limited to being bad in one way, they are not even limited to be at their worst specifically on the issue you care about most. They can be bad in multiple ways at once, and it is worse.
dvogel | 5 hours ago
While I share your concerns and have made similar points in other discussions, I'm trying to point out that there is an additional social offense here that relates to the project (as in the organization of humans around a set of problems) rather than to the code (which is a product or artifact of that project).
simonw | 23 hours ago
Given that Anthropic credited Sapling, and Mononoke is a component of Sapling (the server part of it), I don't find this complaint particularly convincing.
If Anthropic hadn't credited Sapling I'd see their behavior as extremely bad form.
(I'd I was Anthropic I'd update the original announcement to credit Mononoke, too.)
sunshowers | 23 hours ago
Enough, Simon. You have carried enough water for these companies. This is nonsense. This is well beyond "hard-won lessons" — this is a direct copy made by (what I've been told) is an overlapping group of people. Given how contrarian the design was back then, and still is in many ways, it is basic decency to say that the data model is a direct copy (the word "ripoff" has been used).
simonw | 23 hours ago
I agree with you that they should credit the data model to Sapling and Mononoke.
I do not think that their failure to do so in the original post (that credited Sapling) was an outrageous lapse of judgement.
sunshowers | 23 hours ago
I have since privately received information that this was done in bad faith, and that I was far too generous in my post. Does that change your beliefs?
simonw | 23 hours ago
Yes. That's a scandal.
sunshowers | 17 hours ago
Thanks.
FYI in your post you say:
I want to be clear that it isn't just the concept of derived data that is inspired by Mononoke. A Scion changeset is almost exactly the same as what we in Mononoke called a Bonsai changeset. I led the design and initial implementation work for Bonsai changesets back in 2018, including writing the four canonical design documents that are still the reference. The advantages of Bonsai changesets are very non-obvious until you spend a great deal of time thinking about the problem, which I had given my years of experience on version control.
This is not surprising given the additional information I received later, which includes the fact that Claude was pointed directly at Mononoke and told to copy it. The fact that none of this is even remotely hinted at is shameful; taking an existing battle-tested (over a decade!) design and copying it in 5 months is much less impressive than coming up with a brand new design and productionizing it in 5 months.
edit to add that there are also other parts such as an API to do source control queries and mutations with that are copied from Mononoke. Those have been done elsewhere before Mononoke, too. In general it is always good to situate your work in the larger context of what came before you.
gasche | 13 hours ago
I work in public research, and I recognize this situation as "you should write a paper about this". The description that you use in your post comes from, if I understand correctly, personal documents you wrote for a job application. Curiosity question: have you / your team considered writing actual papers / public technical reports about these things? (Why not?)
sunshowers | 6 hours ago
Let's just say I wasn't as writing-pilled back then as I am now, especially after I joined Oxide.
k749gtnc9l3w | 12 hours ago
I did say in the comments to Anthropic post, that they don't say enough to figure out what they took and combined from known and tried ideas.
I would say that stressing derived data (as in your main pot) does not really feel like much more convincing, as derived data at the level they describe it is just database indexing and caching, so who knows.
But the claim you make here in the comment, this one is a damnable omission on their part. What exactly goes into the changeset in Bonsai is clearly a careful optimisation for a monorepo use case (my dream DVCS for personal use would have functionality incompatible with that!), and when they closely followed that, it's a clearly more of a fork/rewrite than «hard-won lessons», and yeah, that needed to be explicitly credited to Mononoke and Bonsai changesets.
sunshowers | 5 hours ago
Thanks. I've expanded on that in a followup. The original was written while I was upset, and was not my clearest technical writing.
k749gtnc9l3w | 4 hours ago
Thanks a lot, that was much more substantial to read than the first version!
Re: contrarian — as a happy Monotone (a completely different and much older Mono?o?e VCS!) user and someone who packages enough stuff to have been forced to use Darcs slightly outside the happy path, I would say that contrarianism of that approach does not impress me as contrarian, but figuring out exact details of the core design to mait the throughput goals possible is indeed a great achievement.
sunshowers | 4 hours ago
The resemblance of the name Mononoke to Monotone is not a coincidence!
k749gtnc9l3w | 3 hours ago
I wonder who will be the first to break, swallow the eventual consistence pill, and remember that both Monotone and Mercurial track branches in a way that allows multiple heads, which avoids full-linearisation requirement. I prefer Monotone's «global branch names, so you cannot avoid multiple heads» approach for small-scale workflow reasons too, but it also hits the nail on the head for a slightly catastrophic scaling-out scenario.
sunshowers | 47 minutes ago
FWIW, I think server-side rebases with the Bonsai model allow you to have a total linear order on main very efficiently. This is what we called "push rebase" -- the original version was done within Mercurial, using files on disk and the Mercurial data model. Mononoke's contribution here was to implement push rebases efficiently using the Bonsai model, in the context of a stateless server built on top of an object store. As you've been able to tell, Bonsai changesets and efficient push rebases were carefully designed to work together and scale up (they've scaled up just fine to an order of magnitude beyond the original design parameters).
k749gtnc9l3w | 37 minutes ago
Linearity still forces one to have a mutex for updating the head position, no? Although with good design it can scale up very well (out, that's harder)
(Also rebases lie about what was tested, but fortunately nobody ever reads history to see those lies)
sunshowers | 15 minutes ago
Yes. The goal of the Bonsai data model is to make that critical section as small, and involve as few pointer chases, as possible.
Agreed that push rebases don't detect semantic merge conflicts across files (they worked at the file and directory level). In massive monorepos this isn't a major problem though, especially because work would generally be done against the latest "warm" bookmark, which meant a bookmark for which the build system had already verified things and cached build results.
sjamaan | 15 hours ago
I'd go further and say it outright shows the touted efficiency gains of LLMs are complete bullshit.
I hope their vibe coded garbage VCS malfunctions and deletes some important code.
mcherm | 22 hours ago
It would certainly change my beliefs if I had any evidence beyond your bare statement.
sunshowers | 21 hours ago
We do not have a trust relationship, so obviously I'm not going to share private correspondence with you. But the public evidence is what it is, and beyond that you'll need to take my word for it.
alper | 13 hours ago
There's enough bad faith to go around in these companies to the point that they really need to prove the contrary.
hjvt | 21 hours ago
Those damn leopards, who would have thonk'd...
altano | 23 hours ago
simonw | 23 hours ago
These days Mononoke lives in sapling/eden/mononoke. Is it really a scandal to credit the parent project and not name the server component directly?
altano | 21 hours ago
That’s very clearly not the objection? I’m confused.
mond | 22 hours ago
How different is Mononoke from Google's Piper (and the layers on top of it, of which there are several)? Is there anyone in the world familiar with both? I feel like it should be easy for some amount of conference evolution to happen here.
riking | 21 hours ago
This is mentioned in the post under the name SrcFS.
mond | 21 hours ago
My understanding is that SrcFS is not quite the same as Piper (or one of the several other tools Google has, all of them vaguely connected).