> is there any real difference between checking out a portion of the tree via a VFS or checking out multiple repositories? There is no difference.
How big is your monorepo? Assume each line of code is a full 80 characters, stored via ASCII/UTF-8. That 67 million lines of code in 5GB. I can fit five of those on a Blu-ray.
> The end result is that the realities of build/deploy management at scale are largely identical whether using a monorepo or polyrepo.
True.
> It might be deployed over a period of hours, days, or months. Thus, modern developers must think about backwards compatibility in the wild.
Depends entire on the application. Lots of changes are deployed within short periods of time with low compatibility requirements.
> Downside 1: Tight coupling
Monorepos do often have tightly coupled software. Polyrepos also often have tightly coupled software. Polyrepos look more decoupled, but pragmatically I can't say I've noticed a much of difference.
> Downside 2: VCS scalability
I've also heard Twitter engineers complain about the VCS. But what is the scope of the author's discussion? 1,000 engineer orgs? Or 20 engineer orgs? Those are vastly different levels of engineering collaboration. I assume the article was not written to cover both of those. Or was it?
---
Ultimately, I think the author implicitly assumed a universe of discourse of gigantic repos with hundreds and hundreds of daily contributors.
When people talk about the spectrum of monorepo vs polyrepo architectures, that is very extreme. For example, last I knew, Uber has more repos than it did engineers. And I don't assume that "polyrepos" always means multiple repos per engineer.
How big is your monorepo? Assume each line of code is a full 80 characters, stored via ASCII/UTF-8. That 67 million lines of code in 5GB. I can fit five of those on a Blu-ray.
> The end result is that the realities of build/deploy management at scale are largely identical whether using a monorepo or polyrepo.
True.
> It might be deployed over a period of hours, days, or months. Thus, modern developers must think about backwards compatibility in the wild.
Depends entire on the application. Lots of changes are deployed within short periods of time with low compatibility requirements.
> Downside 1: Tight coupling
Monorepos do often have tightly coupled software. Polyrepos also often have tightly coupled software. Polyrepos look more decoupled, but pragmatically I can't say I've noticed a much of difference.
> Downside 2: VCS scalability
I've also heard Twitter engineers complain about the VCS. But what is the scope of the author's discussion? 1,000 engineer orgs? Or 20 engineer orgs? Those are vastly different levels of engineering collaboration. I assume the article was not written to cover both of those. Or was it?
---
Ultimately, I think the author implicitly assumed a universe of discourse of gigantic repos with hundreds and hundreds of daily contributors.
When people talk about the spectrum of monorepo vs polyrepo architectures, that is very extreme. For example, last I knew, Uber has more repos than it did engineers. And I don't assume that "polyrepos" always means multiple repos per engineer.
reply