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...
This is not really an issue, because it depends on your local project files, not on the size of the repository. You only have problems with the IDE in a large project such as Chrome. Most projects will have moderate sizes that can still be handled by Eclipse.
* Mapping the repository into the filesystem requires drivers which can add a whole dimension of fun if one has to support a larger team over multiple platforms.
* Doing replication is hard if you want uptimes of 99.9x%
Yes, done right it can work great. But usability does not degrade gracefully when things break.
CitC clients takes seconds, many IDEs work (some better than others with dedicated/volunteers to support), internal GUI based versioning, code reviewing, testing, documenting, bug tracking tools also work at scale.
This has been a problem, despite being at Google.
benefits of monorepo
* change code once, and everyone gets it at once
* all third party dependencies get upgrade at once for the whole company
cons (if you are not google)
* 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
* even after stringent code reviews, bad code gets checked in and break multiple projects not just your team's project.
* 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
* GUI based git tools like Tower/Git Source dont work as they cant handle such a large git repo
Google has solved all the issues i mentioned above so they are clearly an exception to this but for rest of the companies that like to ape google, stay away from monorepo