4 ms·

Pondering a Monorepo Version Control System

• galaxyLogic 7y ago
  > 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 7y ago
    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 7y ago
      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?