3 ms·

(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

by 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.
        Groxx 9y ago
        or you give your CI the ability to read transaction markers in your git repo. e.g. add a tag that says "must have [repo] at [sha]+". dependency management basically. you can even do this after the commits are created, so you can allow cycles and not just diamonds. but yes, cross-project commits are dramatically easier in a monorepo, I entirely agree with that - they essentially come "for free".
        joshuamorton 9y ago
        Didn't you just reinvent versioning and frozen dependencies? What you described is not always building at latest, it's building at latest except when there are issues at which point you don't build at latest and instead build at a known good version. Consequences of this are, for example, that you cannot run all affected tests at every commit.

by Groxx 9y ago

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.
      - Groxx 9y ago
        or you give your CI the ability to read transaction markers in your git repo. e.g. add a tag that says "must have [repo] at [sha]+". dependency management basically. you can even do this after the commits are created, so you can allow cycles and not just diamonds. but yes, cross-project commits are dramatically easier in a monorepo, I entirely agree with that - they essentially come "for free".
        joshuamorton 9y ago
        Didn't you just reinvent versioning and frozen dependencies? What you described is not always building at latest, it's building at latest except when there are issues at which point you don't build at latest and instead build at a known good version. Consequences of this are, for example, that you cannot run all affected tests at every commit.