Why does Meta (Facebook) use mono-repo in their source control? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Because this question may lead to opinionated discussion, debate, and answers, it has been closed. You may edit the question if you feel you can improve it so that it requires answers that include facts and citations or a detailed explanation of the proposed solution. If edited, the question will be reviewed and might be reopened.

Closed last year.

Improve this question

Meta maintains all their code in a single repository and initially used Git. Due to performance issues attributed to the repo's size, they consulted Git's team, who suggested switching to a multi-repo structure. Meta declined this advice and migrated to Mercurial instead.

Given this background, I'm curious about the benefits of using a mono-repo, particularly for Meta's scenario.

Is there a compelling reason for the company to employ version control in this manner?

• JimmyJames: Why do you assume there are advantages?
• just_a_developer: @JimmyJames because Meta told their problem to Git, Git team adviced Meta to switch to multi-repo, but they prefered to switch to Mercurial instead. Also, I think mono-repo is bad, but if a huge company like Meta decided to use it, maybe there is something critical they need
• JimmyJames: The (somewhat depressing) reality of the software industry is that the success of a software company often has very little to do with the skill of their software engineers. Don't get me wrong, I'm sure Facebook has great engineers but this smells like a mistake that was deemed too expensive to fix by the same management that allowed it to happen in the first place.
• just_a_developer: @JimmyJames I see, you can be right. And then they say positive stuff about it, "rationalizing" it, like you said
• Community: Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.

Answer 1

The closest thing to an official answer:

Our code base has grown organically and its internal dependencies are very complex. We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using a single repository. Even at our current scale, we often make large changes throughout our code base, and having a single repository is useful for continuous modernization. Splitting it up would make large, atomic refactorings more difficult.

With a mono-repo you can refactor both sides of an API at the same time and commit the change atomically. In other words, it's a mono-repo to support what is effectively a mono-lith: a single giant tightly coupled codebase.

• JimmyJames: I don't buy it. Seems like a rationalization to me.
• just_a_developer: @pjc50 I see, so their use case is a very fast changing code base, which also grows in developers using it. So, they don't wanna pay the cost of making it modular, and prefer being able to refactor and reuse code agressively...
• just_a_developer: @JimmyJames yeah, maybe not worth it for 99% companies. I imagine they have to deal with conflicts all the time, version issues, etc.
• JimmyJames: @just_a_developer I'd love to know what that actually looks like in practice. Coordinating a change like that across a company of that size must be really fun. I know all the developers that I've worked with love it when they are required to accept changes without regard to what they are in the middle of.
• amon: @just_a_developer You're talking about refactoring like it's a bad thing. Software changes because requirements change, so tooling should support change. I cannot safely change a component if someone may be depending on it, in another repo that I don't even know exists. So I can either do the Amazon thing and commit to API stability, at the cost of making breaking changes incredibly expensive. Or I can use the FB/Google/Linux-Kernel way and keep everything in one repo, enabling cross-cutting changes. Yes, the Kernel, the project for which Git was designed, uses a monorepo.

Answer 2

Meta maintains all their code in a single repository and initially used Git

is that really true?

https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/

says:

..our then-current technology, a Subversion server with a Git mirror..

and the other famous example of google..

https://qeunit.com/blog/how-google-does-monorepo/

Historically under CVS, the source code was quickly migrated to Perforce.

The problems of branching in perforce and subversion are very different to git. gits branching model solves many of the issues with older styles of source control.

I would venture to suggest that people make mono repos because they heard google and facebook did, not because they hit the same problems.

If we dig into google's solution, we can see there is a selective compilation of changes, it's kind of split up into components even if its called a mono-repo.

Facebook famously uses PHP, an interpreted language. Naively used, you need all the source code to run it, no dlls, so no separate repos.

My take away from these, admittedly sparse articles, is that google and meta found it too hard to refactor to a componentized version of their software products. Instead they attacked the face value problems the developers were experiencing, Slow branching and merging of massive codebases, by optimising the source control software.

Those of us old enough to remember SourceSafe will know the pain of slow source control and copying all the files just to make a branch. When someone comes along and makes it 10x faster, that's great and you jump at it. But I don't think I would go back from git's delta based model and any to any merges for love nor money