This line about the monorepo from the Dan Luu post always confuses me:

> With a monorepo, you just refactor the API and all of its callers in one commit.

I have experience working a monorepo at a mid-sized tech company (~1000 developers) and with Brazil at Amazon (tens of thousands of developers).

It's true that at my monorepo company, that's how we did it. However, I don't understand how this would work at Amazon's scale—for some packages you simply cannot update all the consumers at once and also as the vendor of an API, it's not my job to update the consumers. So I need to be able to have multiple versions of my interface resident at the same time. Brazil solves this problem with version sets.

How is it solved in these vaunted monorepos at Facebook and Google? If there are N core libraries that each have two versions of their APIs, it it possible for consumers to each pick and chose which APIs to use, or it enforced that libraries just have one version that is "live" at any time?

In general, most of these companies have automated tools to accomplish things like this. If you look at Steve Yegge's recent rant about GCP, you'll note that he mentions this as a use case for his tool, Grok. Link: https://medium.com/@steve.yegge/dear-google-cloud-your-depre...

That is a tool for doing the refactor, right? What if you don't want to do it all at once. Is that something Google's software repo can support?

> A while ago, I pondered monorepo version control systems. This article is at the opposite end of the spectrum: Manyrepos.

The opposite of mono- is poly-, though.

Using many- is kind of confusing when spoken:

> Unfortunately, in manyrepo environments...

Sounds and almost reads like "in many repo environments", which has a different meaning.