Having hundreds of developers work on the same code repository seems insanely complicated. What are the advantages? Where can I read more about monorepos?
They do not use an usual git repository. Companies using monorepos have tools to restrict people's access to parts of it, and filter log noise.
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.
The feature I missed about Subversion was, if you could figure out how to treat your code like a proper tree, individual teams would check out one, maybe two directories, and only the leads and operational people ever had the whole thing.
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.
Versions are a tree structure. The implementation may have required the next revision number to be n + 1, but the data structure does not necessarily have to do that. If myself and someone else push commits, they have to be rebased and renumbered anyway, right?
We are just 2 devs at the moment and we've setup Lowdefy with a monorepo and yarn 2 and I can add that even for small projects a monorepo is just bliss especially with yarn 2 and lerna!
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.
Sort of, the google3 monorepo is so large that all checkouts are sparse checkouts. So you have a virtual checkout of everything but specify the subset you actually need.
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.
There's lots of writing about monorepos these days, and they're quite common in public projects though usually at a smaller scale (ex. React is a monorepo, so is Babel and VSCode).
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.
> Google built their VCS from scratch in house for scale
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).
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.