3 ms·

So why is this a problem for a monorepo but not the multi-repo? It seems to me that the major difference is that in a multi-repo, you'd be more likely to be obl

So why is this a problem for a monorepo but not the multi-repo? It seems to me that the major difference is that in a multi-repo, you'd be more likely to be oblivious to the multitude of dependency issues than you are in the monorepo... and to be honest, that actually sounds like a bad thing to me, because it means you're sweeping legitimate issues underneath the rug.

taeric 4y ago
In a multi-repo, you don't build source dependencies between projects. You can do this with a mono, as well. However, the conceit is that "in the same repo" means you can "change them together." It is very very tempting that "went out as a single commit" means that it went out fine. Which, just isn't something you see in a multi world.
- jcranmer 4y ago
  > In a multi-repo, you don't build source dependencies between projects. In my experience with software projects, this is very much not the case. It's one of the main reasons I'm such a big fan of monorepos--I have been burned way too many times by the need to make atomic commits involving separate repositories.
  - taeric 4y ago
    If you have multiple repos, you can't have an atomic commit between them. Pretty much period. I'm scared to hear what you mean on that. Ideally, all tooling makes the separate nature of the projects transparent. They should test separately. They should deploy separately. If that is not the case, then yes, they should be in the same repo.
    - I_AM_A_SMURF 4y ago
      I've worked at places where they would "solve" this problem by letting the build break while all the commit in various repositories land all at once. It's really bad.
- jmillikin 4y ago
  > However, the conceit is that "in the same repo" means you can > "change them together." In a monorepo you shouldn't be making changes to independent components in a single commit. That's how you end up being forced to roll back your change because you broke someone else's service. If you're making a backwards-incompatible change to an API then you need to: 1. Make a commit to your library to add the new functionality, 2. Send separate commits for review by other teams to update their projects' code, 3. Wait for them to be approved and merged in, then merge a final cleanup commit. If your repository is designed to enable a single commit to touch multiple independent projects then it's not a monorepo, it's just a single-project repo with unclear API and ownership boundaries.
  - taeric 4y ago
    This is clearly correct. But even in a multi world, I've seen far more attempts at atomic commits than makes sense. I'd love for it to be a strawman. But I do keep finding them. You do get me to question what a mono repo is. I've never seen one that wasn't essentially an attempt at treating a company as a large project. Akin to a modular codebase with a single build. Could be a complicated build, mind you. Still, the goal has always been a full repository build.

taeric 4y ago

In a multi-repo, you don't build source dependencies between projects. You can do this with a mono, as well. However, the conceit is that "in the same repo" means you can "change them together." It is very very tempting that "went out as a single commit" means that it went out fine. Which, just isn't something you see in a multi world.

jcranmer 4y ago
> In a multi-repo, you don't build source dependencies between projects. In my experience with software projects, this is very much not the case. It's one of the main reasons I'm such a big fan of monorepos--I have been burned way too many times by the need to make atomic commits involving separate repositories.
- taeric 4y ago
  If you have multiple repos, you can't have an atomic commit between them. Pretty much period. I'm scared to hear what you mean on that. Ideally, all tooling makes the separate nature of the projects transparent. They should test separately. They should deploy separately. If that is not the case, then yes, they should be in the same repo.
  - I_AM_A_SMURF 4y ago
    I've worked at places where they would "solve" this problem by letting the build break while all the commit in various repositories land all at once. It's really bad.
jmillikin 4y ago
> However, the conceit is that "in the same repo" means you can > "change them together." In a monorepo you shouldn't be making changes to independent components in a single commit. That's how you end up being forced to roll back your change because you broke someone else's service. If you're making a backwards-incompatible change to an API then you need to: 1. Make a commit to your library to add the new functionality, 2. Send separate commits for review by other teams to update their projects' code, 3. Wait for them to be approved and merged in, then merge a final cleanup commit. If your repository is designed to enable a single commit to touch multiple independent projects then it's not a monorepo, it's just a single-project repo with unclear API and ownership boundaries.
- taeric 4y ago
  This is clearly correct. But even in a multi world, I've seen far more attempts at atomic commits than makes sense. I'd love for it to be a strawman. But I do keep finding them. You do get me to question what a mono repo is. I've never seen one that wasn't essentially an attempt at treating a company as a large project. Akin to a modular codebase with a single build. Could be a complicated build, mind you. Still, the goal has always been a full repository build.