http://blog.xebia.com/monorepos-for-true-ci/
http://blog.shippable.com/our-journey-to-microservices-and-a-mono-repository
https://medium.com/@Jakeherringbone/you-too-can-love-the-monorepo-d95d1d6fcebe
https://www.pantsbuild.org/index.html
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
- Easy single view of all open PRs
- Every project will use same workflow (can't having diverging branching models across projects)
- Have to setup IDEs less often (no need to setup Intellij 10x for 10 different repos for example)
- Code sharing/reuse is discouraged in multi-repo due to the overhead. Suppose module A and B would naturally both depend on C, but instead they each have their own implementation, say C_A and C_B. Now if a fix/feature is applied to one, say C_A, it won't get propogated to C_B, or we have to fix the bug twice. In large projects this gets much worse.
- Multirepo is an almost irreversible decision, it's hard to go from a multi to a mono, but it's easy to go from a mono to a multi.
Sorting out the gitlab creds plugin in multi-repo has to be done N times, instead of 1.
Upgrading any project to a newer version of a lib has to be done N times, instead of 1.
Divergent codebases due to mismatching libs.
Setting up gitlab settings, like branch protection rules has to be done N times, instead of 1.
All projects can be forced to conformed to same checks, like security checks, file size checks, etc.