[scaleout1]

Please dont do it unless you are google and have built google scale tooling (gforce/big table for code cache)

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

[pmezard]

> 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.

[avita1]

> Also, please compare the easiness of setting up CI for a hundred of repositories compared to a single one with tens thousand of files.

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...

[scaleout1]

Yes this is based on teams of 1000+ developer at a non google company

[cousin_it]

Your complaints are oddly git specific. Why use git with a monorepo? Perforce is simpler and works better.

[slrz]

Yes, Perforce can handle huge repos with gigantic binary files much better than git. Sadly, it sucks at pretty much everything else.

[jonhohle]

Perforce works well for a monorepo at certain scale. It also falls over with too much stuff, and when it falls (due to capacity or otherwise) over your entire company is dead in the water until it's resolved.

[coliveira]

> your IDE (IntelliJ in my case) stops working because your project has million of files.

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.

[heisenbit]

To add based on the experience of running ClearCase in a 3 place multi-site setup in the past:

* 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.

[SonicSoul]

Why couldn't you push/pull feature branches instead of the whole thing? That should still be fast

[iamchrisle]

The major build tools are insanely powerful, pragmatic, and maintained by dedicated teams. Volunteers also add features as needed.

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.

[shaftway]

> even after stringent code reviews, bad code gets checked in and break multiple projects not just your team's project.

This has been a problem, despite being at Google.

[desireco42]

GUI based Git tools got me to chuckle :) (oh, ok I am smug)