| > git checkout takes several minutes X number of devs in the company
> git pull takes several minutes X number of dev
> people running get fetch as a cron job, screwing up and getting into weird state I feel like you are addressing teams of several hundreds of developers. Unless they commit large binary files each day this is hardly an issue for smaller several tens people teams. > even after stringent code reviews, bad code gets checked in and break multiple projects not just your team's project. Revert such code immediately once detected by the CI. Which is harder to do if the changes and their adjustments are spread across dozen of repositories. Also, please compare the easiness of setting up CI for a hundred of repositories compared to a single one with tens thousand of files. > your IDE (IntelliJ in my case) stops working because your project has million of files. Require creative tweaks to only include modules you are working on. Monorepo does not mean you have to load everything in a single workspace. It means everything gets committed at once. If your tools cannot handle so many files or cannot be configured to work on subsets, blame your tools. Yes, monorepo present some challenges but handling hundred of repositories is no better. Having done both, I prefer the former. And yes not everyone is Google, with thousand of developpers and billion lines of code. |
It's not so black and white though. There's plenty of difficulty in keeping a mono-CI system running and being helpful.
* The CI service becomes a single point of failure for all developer productivity
* Running a full build on every commit while accounting for semantic merge issues (so serially) is non trivial.
Jane Street did a pretty good write up of how hard this can be: https://blogs.janestreet.com/making-never-break-the-build-sc...