Some recent related discussions on this tip:
Ask HN: Can we do better than Git for version control? (December)
https://news.ycombinator.com/item?id=38590080
I kind of killed Mercurial at Mozilla (November)
Why Facebook doesn't use Git
11–20 of 22 posts
Re: Why Facebook doesn't use Git
#12I thought most of the reasons - not being welcomed to modifying git - were known already for someone who went looking, but seeing the quotes from ex facebookers is interesting.
I’d be more interested in why facebook ditched mercurial for their own. Once they left more and more notable projects left, though for more than that as reason. The mercurial project is still under development but it feels like a ghost town. It’s a shame as I much prefer mercurial to git but it’s difficult to choose as an option when the integrations and tooling is lacking, and new tool development is less likely to integrate with mercurial when it has so little resources behind it.
Re: Why Facebook doesn't use Git
#13Microsoft had issues git’s ability to scale. According to this[1] they found and submitted solutions to allow git to scale to their needs and worked with the git team. It sounds like Facebook wasn’t partnering with them to solve the problem? The article mentions Microsoft had repos with 6m files and says things now take seconds.
I’m not personally dealing with repos of this size, but it sounds like this is a problem of the past, thanks to Microsoft. I have a hard time believing Facebook would be a bigger beast than Windows.
[1] https://devblogs.microsoft.com/bharry/scaling-git-and-some-b...
Re: Why Facebook doesn't use Git
#14Microsoft had issues git’s ability to scale. According to this[1] they found and submitted solutions to allow git to scale to their needs and worked with the git team. It sounds like Facebook wasn’t partnering with them to solve the problem? The article mentions Microsoft had repos with 6m files and says things now take seconds. I’m not personally dealing with repos of this size, but it sounds like this is a problem…
It’s remarkable they’re the same company that gave the world Sourcesafe…
Re: Why Facebook doesn't use Git
#15Git and Mercurial came out the same year. Both were created due to changing licenses of BitKeeper and how this would affect Linux kernel development.
Re: Why Facebook doesn't use Git
#16Microsoft had issues git’s ability to scale. According to this[1] they found and submitted solutions to allow git to scale to their needs and worked with the git team. It sounds like Facebook wasn’t partnering with them to solve the problem? The article mentions Microsoft had repos with 6m files and says things now take seconds. I’m not personally dealing with repos of this size, but it sounds like this is a problem…
If you have infinite engineering resources to throw at a problem, seems best to consider multiple avenues. Sure, you could make patches to git, hope they get upstreamed, probably have to maintain an internal fork for years. Or design a system designed around the idea of huge repos.
Re: Why Facebook doesn't use Git
#17Ctrl+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…
[deleted]
Re: Why Facebook doesn't use Git
#18Ctrl+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…
I prefer the term "derived" from Mercurial. It was Mercurial and slowly but steadily morphed into what's a custom VCS now.
Re: Why Facebook doesn't use Git
#19Microsoft had issues git’s ability to scale. According to this[1] they found and submitted solutions to allow git to scale to their needs and worked with the git team. It sounds like Facebook wasn’t partnering with them to solve the problem? The article mentions Microsoft had repos with 6m files and says things now take seconds. I’m not personally dealing with repos of this size, but it sounds like this is a problem…
It’s remarkable they’re the same company that gave the world Sourcesafe…
Shudder
Re: Why Facebook doesn't use Git
#20Earlier quoted context omitted.
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 G…
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).