3 ms·
Another problem is that a single repo for all the code you run is impossible for all but the biggest companies (Google). Most of the code that you run is open
by catern 9y ago
Another problem is that a single repo for all the code you run is impossible for all but the biggest companies (Google).
Most of the code that you run is open source dependencies, like the Python interpreter, GNU C library, and Linux kernel.
You could import everything, including outside dependencies, into a single repo and build an OS/application image from that repo. That is effectively what Google does. But that requires a lot of careful attention to pulling in updates of external code, and requires a particularly excellent build and dependency manager (aka a package manager). It is also huge enough to run into serious performance problems no matter how you try to fix it.
So more practically, your monorepo is just for your internal code. Which means if you ever want to fix a bug in any outside libraries, or make some of your code available as a separate library for the outside world, you need to work with multiple repos.
So why not just be multi-repo from the start? Or rather, have multiple monorepos, one per project or group.