4 ms·

What changes can you do that you couldn't have done before, in a multirepo world? And I do mean could not have done - clearly the monorepo enjoys a few hundred

by Groxx 9y ago

What changes can you do that you couldn't have done before, in a multirepo world? And I do mean could not have done - clearly the monorepo enjoys a few hundreds of thousands (millions?) of hours of effort that the multirepo did not. i.e. what stops your current tools from `for each repo, run...`, or how is monorepo fundamentally more capable than building automated library management / releases / etc with the same level of tooling?

londons_explore 9y ago
With a single commit you can change an API, and all it's users, and run all the tests for all the dependant projects, etc, and you're done. All in a days work, and no emails/communication necessary. In a multi-repo world, people are probably linking against old revisions of your library, and against certain tags/branches etc. There is probably no overarching code search to find all users of the API. You're gonna have to grep the code and hope to find all uses. You might miss some repos/branches. Everyone has their own continuous integration/testing procedures, so you can't easily migrate their code for them. You're gonna have to support both API's for probably months until you have persuaded every other user to upgrade to the latest 'release' of your code which supports the new API before finally turning off the old API. The work involved in the migration is spread amongst all the project owners, which is probably much less efficient. As others have said, it's the fully integrated version consistent codesearch with clickable xrefs across gigabytes of source code, cross repo code review, cross-repo testing, etc. which really makes a monorepo work well.
- Groxx 9y ago
  (edit: shortened dramatically. apologies, earlier wasn't all that useful.) With the exception of cross-repo code review (I hadn't thought of that one - would be useful for multi-repo too, but I've honestly never seen a multi-repo tool for this, thanks!), this is all just the benefits of standardization, plus a massive injection of tooling enabled by the standards. Standardization of projects brings huge benefits when it's done right, absolutely agreed. But that's entirely orthogonal to mono vs multi.
  - joshuamorton 9y ago
    Not really. The point is that you can't have the same level of standardization in a multi repo set up.
    - Groxx 9y ago
      for repo in ls repos do thing done ?
      - joshuamorton 9y ago
        Diamond dependency like issues crop up. Imagine I have Repos A,B,C. A is a base repo. B and C depend on A, and C also depends on B. If I modify some API in A, and also update all the callsites in B and C, I also have to bump the version of A depended on by B and C, and also bump the version of B that C depends on, otherwise I'll get version mismatch/api compatibility breakages. To make this work that means that nothing can depend on latest, everything has to have frozen dependencies, and you either need to manually, or via some system, globally track all of the dependencies across repos, and atomically update all of them on every breaking change. In other words, you reinvent blaze/bazel at the repo level instead of the target level, and you have to add an additional tool that makes sure you're dependencies can never get mismatched. The monorepo sidesteps this issue by saying "everything must always build against latest".
        Groxx 9y ago
        "everything must always build against latest" is perfectly enforceable on multirepo too, it's just that nobody does it.
        joshuamorton 9y ago
        >"everything must always build against latest" is perfectly enforceable on multirepo too, it's just that nobody does it No, you cannot. That's my entire point. Here's a minimal example: Repo one contains one file, provider.py: def five(): return 5 Repo two contains one file, consumer.py. import provider # assume path magic makes this work def test_five_is_produced(): assert provider.five() == 5 if __name__ == '__main__': test_five_is_produced() I also have an external build script that copies provider and consumer, from origin/master/HEAD into the same directory, and runs `python consumer.py`. Now I want to change `five` to actually be `number`, such that `number(n) == n`, ie. I really want a more generic impl. What sequence of changes can I commit such that tests will always pass, at any point in time? There is no way to atomically update both provider and consumer. There will be some period of time, perhaps only milliseconds, but some period of time, at which point I can run my build script and it will pick up incompatible versions of the two files. This is a reductive example, but the function `five` in this case takes the role of a more complex API of some kind.

by Groxx 9y ago

londons_explore 9y ago

With a single commit you can change an API, and all it's users, and run all the tests for all the dependant projects, etc, and you're done. All in a days work, and no emails/communication necessary. In a multi-repo world, people are probably linking against old revisions of your library, and against certain tags/branches etc. There is probably no overarching code search to find all users of the API. You're gonna have to grep the code and hope to find all uses. You might miss some repos/branches. Everyone has their own continuous integration/testing procedures, so you can't easily migrate their code for them. You're gonna have to support both API's for probably months until you have persuaded every other user to upgrade to the latest 'release' of your code which supports the new API before finally turning off the old API. The work involved in the migration is spread amongst all the project owners, which is probably much less efficient. As others have said, it's the fully integrated version consistent codesearch with clickable xrefs across gigabytes of source code, cross repo code review, cross-repo testing, etc. which really makes a monorepo work well.

Groxx 9y ago
(edit: shortened dramatically. apologies, earlier wasn't all that useful.) With the exception of cross-repo code review (I hadn't thought of that one - would be useful for multi-repo too, but I've honestly never seen a multi-repo tool for this, thanks!), this is all just the benefits of standardization, plus a massive injection of tooling enabled by the standards. Standardization of projects brings huge benefits when it's done right, absolutely agreed. But that's entirely orthogonal to mono vs multi.
- joshuamorton 9y ago
  Not really. The point is that you can't have the same level of standardization in a multi repo set up.
  - Groxx 9y ago
    for repo in ls repos do thing done ?
    - joshuamorton 9y ago
      Diamond dependency like issues crop up. Imagine I have Repos A,B,C. A is a base repo. B and C depend on A, and C also depends on B. If I modify some API in A, and also update all the callsites in B and C, I also have to bump the version of A depended on by B and C, and also bump the version of B that C depends on, otherwise I'll get version mismatch/api compatibility breakages. To make this work that means that nothing can depend on latest, everything has to have frozen dependencies, and you either need to manually, or via some system, globally track all of the dependencies across repos, and atomically update all of them on every breaking change. In other words, you reinvent blaze/bazel at the repo level instead of the target level, and you have to add an additional tool that makes sure you're dependencies can never get mismatched. The monorepo sidesteps this issue by saying "everything must always build against latest".
      - Groxx 9y ago
        "everything must always build against latest" is perfectly enforceable on multirepo too, it's just that nobody does it.
        joshuamorton 9y ago
        >"everything must always build against latest" is perfectly enforceable on multirepo too, it's just that nobody does it No, you cannot. That's my entire point. Here's a minimal example: Repo one contains one file, provider.py: def five(): return 5 Repo two contains one file, consumer.py. import provider # assume path magic makes this work def test_five_is_produced(): assert provider.five() == 5 if __name__ == '__main__': test_five_is_produced() I also have an external build script that copies provider and consumer, from origin/master/HEAD into the same directory, and runs `python consumer.py`. Now I want to change `five` to actually be `number`, such that `number(n) == n`, ie. I really want a more generic impl. What sequence of changes can I commit such that tests will always pass, at any point in time? There is no way to atomically update both provider and consumer. There will be some period of time, perhaps only milliseconds, but some period of time, at which point I can run my build script and it will pick up incompatible versions of the two files. This is a reductive example, but the function `five` in this case takes the role of a more complex API of some kind.