Having hundreds of developers work on the same code repository seems insanely complicated. What are the advantages? Where can I read more about monorepos?
Or, in other words, it's not that insanely complicated, because they have tools that make it look a lot like multiple repositories. And the large companies using multiple repositories have tools that make them look just like those monoreps. And HN has all those interesting threads full of people saying why one is better than the other.
I never entirely understood what it was in subversion's internals that prevented it from being used as a DCVS. We could figure out version numbers with branches and multiple repos. If not then, certainly now.
There's a space between subversion and Git that could be occupied with something that sheds the worst behaviors of each and makes something better.
We come from separate repos on past versions of the code and the monorepo setup has sped dev up dramatically, even for a team of 2. Having the docs next to our code and autogen some of it from the source code, all is the same repo is just one advantage.
It's a small project but you can view the setup here: https://github.com/lowdefy/lowdefy
You can read a bit about the approach’s benefits and drawbacks from someone at Google here: https://medium.com/@Jakeherringbone/you-too-can-love-the-mon...
Once you have the tooling to do this you can use the monorepo to store all kinds of interesting things, like built artifacts or the contents of the CDN, since it's basically just a giant hierarchical KV store with a global version.
https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
While complicated, in my experience the tooling to get the same productivity from hundreds of separate repos is at least as complicated and generally discourages folks from contributing to codebases outside their own.
Our monorepo encourages a collective velocity culture where everyone is pushing every project forward. If you upgrade React or Node, fix a security issue, or implement an optimization, the hundreds of apps are all improved at the same time. It's harder for one team to "leap forward" in terms of tech stack quickly, but at the same time it's far less likely we end up with hundreds of outdated or abandoned codebases since everyone is collectively improving the repo together.
For example I've rarely seen a single engineer upgrade a thousand separate projects across a thousand git repos with complex nested dependencies very successfully, but that happens every day in our monorepo.
https://research.google/pubs/pub45424/
That said (1) “you are not Google” as the saying goes (2) Google built their VCS from scratch in house for scale.
However it’s not tops hard to do this with just git and some rules/patterns for organization.
It's more complicated than that. Initially, there was Perforce. Then, Google grew client-side tooling on top of that ("g4", rather than "p4"). Then, someone grew client-side Git on top of that (for reasons, good or bad). And at some point, the Perforce backend simply stopped scaling, and a new backend was written (named "piper", but not the "piper" most non-Googlers think of). And once that was in place, assorted more "make it scale" tooling could be built on top of that (and, at that point, I stopped using the client-side Git, because CitC was simply That Good).
So, "from scratch" is a bit of a stretch.