This talks about the tooling investment required for a monorepo, but doesn’t address the tooling investment required for multi-repos, which I would argue is far more. Versioning dependencies between services is a hard problem, and a place like Amazon which uses multi-repos internally still hasn’t figured it out.
Having worked on toolings for monorepo, i would say its fair to say that there are painpoints and tradeoffs at 2 sides of the spectrum.
Today, the best is middle ground wgere you have a set of ‘macro repos’ separated by toolings/platform/infra needs.
There are certainly pain-points for a monorepo, but they have known, good solutions (though they may require a high technical investment). I haven’t seen a good solution to the multi-repo versioning dependency problem yet. I agree that both sides have pain-points but I would argue multi-repos has a huge pain-point with no good solution, which in my opinion makes it a non-starter.
I would be really interested to see further developments in the multi-repo world and be proven wrong, but as far as I can tell most solutions revolve around building a “meta” VCS around the various repositories to try to replicate the atomic commit behavior. At a certain point, is the only downside to a monorepo the performance? (And this is semi-limited to Git, as from my understanding Mercurial has better monorepo characteristics which Meta is investing in)
Author here. Absolutely. I was working on Kubernetes during the early phases where the API client and types were being transitioned out of the monorepo to their own projects. It was a convoluted staging and sync process that made some of dependency hell problems untenable.
There’s probably some sort of relation to Conway’s law – where you are shipping your org chart, but the underlying services are severely codependent.
The only problem with monorepos that I’ve ever seen as a build engineer and developer and SysAdmin for 20 years is git. Don’t get me wrong I love git, but it just has this size limitation where it becomes unusable after a certain size. There are ways to get around this, but monorepos are a git problem, not a source code management problem. SCMs like Mercurial and commercial ones like Perforce are great in that you can pretty much throw anything in the repo and it will not affect checkout time after initial checkout, but git OTOH, becomes nigh unusable after a certain size.
It’s kind of interesting how many of the problems the author lists are just GitHub/Gitlab problems.
Everyone I’ve ever met who likes multi repos likes them because they let you develop without scheduled merge windows. This confuses me cause it seems like it should be a discussion between “CI-pulls” vs “devs-push” model.