Large Repos (vs. Git)

https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/

We looked very hard at decomposing it and we found that our workflow just was not amenable to that. You might checkout the discussion on Hacker News and elsewhere and find that other large engineering companies like Google and Facebook reached similar conclusion about their core platforms and have adopted solutions with the same general aim as ours.

https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/

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. On top of that, the idea that the scaling constraints of our source control system should dictate our code structure just doesn't sit well with us.

https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext

Early Google employees decided to work with a shared codebase managed through a centralized source control system. This approach has served Google well for more than 16 years, and today the vast majority of Google's software assets continues to be stored in a single, shared repository.

https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/

https://svnvsgit.com/#git-scalability-for-larger-project-myth

“While Git is used for such renowned open source projects as Linux Kernel, it does not scale well for truly large projects.”
“While Git is successfully used for such crowded open source projects with thousands of involved developers as Linux Kernel, it may not scale well for other large teams with different workflows.”