3 ms·

I get a headache imagining everything Google in a monorepo. So how do you reconcile this single GIT repository approach with Infoworld's "The case against mono

I get a headache imagining everything Google in a monorepo. So how do you reconcile this single GIT repository approach with Infoworld's "The case against monorepos"? [1]: Reason #1. Monorepos go against single-team ownership principles Reason #2. Monorepos encourage bad practices involving massive refactoring Reason #3: Small repositories are better than large ones [1] https://www.infoworld.com/article/3638860/the-case-against-monorepos.html https://www.infoworld.com/article/3638860/the-case-against-m...

pphysch 4y ago
One person's STOP is another's silo One person's massive refactoring is another's tech debt reduction One person's multirepo is another's inability to find that broken bit of upstream code
scarmig 4y ago
With regard to 3: > In Google’s case, more than 45,000 changes are made to its monorepo every day. This code management becomes an exponential problem in overhead as the number of developers of an application grows, and the number of components within the application expands. Speaking from experience, the overhead of code management is far less at Google than any other place I've worked at, even on projects with just a couple hundred lines of code. If this author is imagining a monorepo means each engineer having to constantly check out terabytes of code to make any change and race with other developers to merge to HEAD, they don't really understand the landscape well enough to write an article criticizing monorepos (which certainly have real cons, particularly with the source control tools that are available to most companies). Of course, you need actual tooling and infrastructure for that beyond what git offers.
wtetzner 4y ago
I think the biggest problem here is that git (out of the box) is not well suited to a monorepo. But in terms of the reasons in "The case against monorepos": > Reason #1. Monorepos go against single-team ownership principles I think it's up for debate about whether or not single-team ownership is desirable. But even if it is, I don't see the difference. Just have teams own their directories within the monorepo. If you want to enforce that a team owns a particular part of the repo, just put some rules into the code review tool to ensure that a change to that component can't be merged without someone from that team reviewing/approving it. > Reason #2. Monorepos encourage bad practices involving massive refactoring Again, this just appears to be the author's opinion that massive refactoring is somehow problematic, without providing much of an argument against it. If you're changing service APIs, then sure, you need to be careful about the order in which you roll out changes. But if you're changing the APIs of shared libraries, then being able to do a single large refactoring is absolutely valuable. > Reason #3: Small repositories are better than large ones This is just a tooling issue. You can still separate projects by directories, and if your tools allow you to just check out a subdirectory, or if you have some sort of virtual filesystem on top of your source control, then you don't have to pay the penalty of pulling down the entire repository.
- cryptonector 4y ago
  > > Reason #3: Small repositories are better than large ones > This is just a tooling issue. You can still separate projects by directories, and if your tools allow you to just check out a subdirectory, ... Even a forest of repos has tooling issues: your build, code review, and code indexing tools will need to support the forest, and that's a lot of work. It's probably comparable to the work needed to make a monorepo work. The alternative to the monorepo isn't all rosy.

pphysch 4y ago

One person's STOP is another's silo One person's massive refactoring is another's tech debt reduction One person's multirepo is another's inability to find that broken bit of upstream code

scarmig 4y ago

With regard to 3: > In Google’s case, more than 45,000 changes are made to its monorepo every day. This code management becomes an exponential problem in overhead as the number of developers of an application grows, and the number of components within the application expands. Speaking from experience, the overhead of code management is far less at Google than any other place I've worked at, even on projects with just a couple hundred lines of code. If this author is imagining a monorepo means each engineer having to constantly check out terabytes of code to make any change and race with other developers to merge to HEAD, they don't really understand the landscape well enough to write an article criticizing monorepos (which certainly have real cons, particularly with the source control tools that are available to most companies). Of course, you need actual tooling and infrastructure for that beyond what git offers.

wtetzner 4y ago

I think the biggest problem here is that git (out of the box) is not well suited to a monorepo. But in terms of the reasons in "The case against monorepos": > Reason #1. Monorepos go against single-team ownership principles I think it's up for debate about whether or not single-team ownership is desirable. But even if it is, I don't see the difference. Just have teams own their directories within the monorepo. If you want to enforce that a team owns a particular part of the repo, just put some rules into the code review tool to ensure that a change to that component can't be merged without someone from that team reviewing/approving it. > Reason #2. Monorepos encourage bad practices involving massive refactoring Again, this just appears to be the author's opinion that massive refactoring is somehow problematic, without providing much of an argument against it. If you're changing service APIs, then sure, you need to be careful about the order in which you roll out changes. But if you're changing the APIs of shared libraries, then being able to do a single large refactoring is absolutely valuable. > Reason #3: Small repositories are better than large ones This is just a tooling issue. You can still separate projects by directories, and if your tools allow you to just check out a subdirectory, or if you have some sort of virtual filesystem on top of your source control, then you don't have to pay the penalty of pulling down the entire repository.

cryptonector 4y ago
> > Reason #3: Small repositories are better than large ones > This is just a tooling issue. You can still separate projects by directories, and if your tools allow you to just check out a subdirectory, ... Even a forest of repos has tooling issues: your build, code review, and code indexing tools will need to support the forest, and that's a lot of work. It's probably comparable to the work needed to make a monorepo work. The alternative to the monorepo isn't all rosy.