
Pondering a Monorepo Version Control System - qznc
http://beza1e1.tuxen.de/monorepo_vcs.html
======
galaxyLogic
> 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.

~~~
qznc
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.

~~~
galaxyLogic
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?

