Pondering a Monorepo Version Control System

beza1e1.tuxen.de

2 points·qznc··3 comments

> In a monorepo you can do an atomic change across everything. This is what enables you to change the API and update all users in a single commit.

I think this begs the question should all software in the whole world be in a single mono-repo?

Assuming you have lots of code which is not in version control, should you put it all into a single mono-repo? Or should you divide it into TWO monorepos? or THREE?

What would be the rule on how many monorepos is best?

I think the rule should be that things which do not or should not depend on each other, should NOT be in the same repo.

The rule does not work right. Let's say A and B do not depend on each other but both depend on C. Now we want all three in the same repo, because if Cs interface changes we can fix A and B in the same change. So even such indirect relationships are relevant.

The rule could be phrased better in terms of what should be in the same repo:

A depends on C therefore A must be in the same repo as C.

B depends on C therefore B must be in the same repo as C.

THEREFORE by logic A and B must (or should) be in the same repo too.

But so in general is this the right direction to be thinking about what all should go into a single mono-repo? And what about big companies who are said to have "everything" in a single repo? Does that make sense?

Reply on news.ycombinator.com