Comment by sneed_chucker | Hacker News Reader

Comment by sneed_chucker | Hacker News Reader

Ctrl+F 'Sapling'

Ctrl+F 'Eden'

Yeah the author of this doesn't really know what's going on with regards to source control at Facebook/Meta.

Meta doesn't actually use Mercurial and hasn't for several years now. They basically wrote their own custom centralized version control that uses Mercurial-inspired client commands in order to adapt to the scale of their massive repos. Actual Mercurial scales just as bad as ever if the repo is too large because that breaks a fundamental assumption of distributed version control.

Massive repos simply don't work with the traditional model of "no master server" distributed version control. In DVCS, a client checkout is supposed to contain the entire repo metadata. That's why the git people told Facebook that they were doing it wrong.

Anyways, stacked diffs are great but they're orthogonal to why Facebook doesn't use git. They use their own thing for the same reason that Google uses piper and why some places still use Perforce. They use it because they want to have massive monorepos and DVCS just doesn't work well for that.

I'm not sure that this continues to be true, now that Git supports partial clones[1]. It's now a fully supported feature in Git to work with only a partial copy of the code and metadata. In my experience, this plus an fsmonitor[2] makes Git work fine on very, very large repos. This is how Microsoft scaled Git to work with their massive Windows monorepo[3]. (That particular article talks about the earlier work using Git VFS, but it eventually turned into these extensions that got upstreamed into Git, as documented in the Scalar repo[4].)

[1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-...

[2] https://github.blog/2022-06-29-improve-git-monorepo-performa...

[3] https://arstechnica.com/information-technology/2017/02/micro...

[4] https://github.com/microsoft/scalar

Yeah, these all seem like parallel or inspired developments of the same thing in git. But they're relatively recent and when you use this stuff git basically ceases to be a DVCS system (though the modern git + GitHub workflow mostly works like centralized version control already)

> GitHub workflow mostly works like centralized version

I mean the actual full DVCS capabilities are rarely used anywhere and aren't appropriate for many people at all. Yes, the Linux kernel uses it. But with the kernel there is no real authorative branch. Yes, there is Linus's and his team's branches but each distro has their own where they pull in patches etc. For a Red Hat user you could say their branches are authorative.

Where in enterprise would you want that? Usually, there is a a team that owns each module, and they are the definitive team and you use their artifacts.

The only case I can imagine a true DVCS workflow is a company I worked at had a core library that we customised and build apps around for clients. There were updates that we would choose to accept that fixed bugs that effected our client, but if they didn't we might not. There were fixes that we couldn't because they clashed with our modifications. This is a situation where true DVCS is applicable. (We didn't use it though, it was copy & paste files from sent emails).

I prefer the term "derived" from Mercurial. It was Mercurial and slowly but steadily morphed into what's a custom VCS now.

Recently open sourced too https://github.com/facebook/sapling

Reply on news.ycombinator.com