4 ms·

Ugh I don't like his use of the word dumbass. Coding is hard, it's easy to break things. We've developed lots of tools of strategies so we don't have to rely on

Ugh I don't like his use of the word dumbass. Coding is hard, it's easy to break things. We've developed lots of tools of strategies so we don't have to rely on people getting it right every time. Branching: getting forked by your worst programmer This example seems contrived I've never worked anywhere where having a fork that works for some scenarios and not others is tolerated for long. This would be given the highest priority. Modularity: demoted from a norm to an ideal This is basically saying a multi-repo makes it hard to reuse your own code which increases modularity. I find devs on very large projects are already reticent to reuse code from other projects/teams, but this pushes them even farther to rewrite domain logic that should probably be shared. In most cases I'd trade a little bit of modularity for increased domain logic consistency. Tooling: is yours better than the standard? There are few organizations that have so much code they break available source control solutions but simultaneously don't have the technical expertise to manage a monorepo that large. For these I guess it makes sense to break it up into manageable peaces based on the relationships between your projects. I've worked on subpar teams that decided against monorepo and it was a nightmare. It took forever to get setup, the build time was days, and cross repo edits were painful. They regretted going multi-repo.

hashkb 7y ago
> We've developed lots of tools of strategies so we don't have to rely on people getting it right every time. I think one of the points of the article is that this isn't (sufficiently) true; people will use tools incorrectly and make excuses for deviating from the strategy often enough that it's a problem. > Ugh I don't like his use of the word dumbass Substitute "well-meaning person who makes a totally understandable process mistake"
- deleted 7y ago
  [deleted]
bartread 7y ago
> cross repo edits were painful. We are moving to a mono-repo for this very reason. Debugging something where you had to make changes to multiple projects, wait for those changes to go through the build pipeline, pull in updated packages in projects that depended on them, then change those projects (and on), was a complete nightmare. We're a bit over halfway there (the most painful half) and I expect us to get the rest done sometime in the next 3 months or so. Not looking back. At all.
CannisterFlux 7y ago
The branching example is very tempting when you have a product that is used on site by multiple customers. Customer A asks for some change that impacts customer B. Without good tests the easiest thing to do is fork the world for A and B, so the changes only impact one. Then you gradually drift apart. Add customer C, D, E... and it gets really fun. With multiple repos it gets even crazier. You have forks for A and B that work with some other software repo, maybe common, maybe forked itself. Soon you have wiki pages with compatibility matrices, common libraries that mysteriously break with minor changes despite being battle tested ... for some set of versions.
- lmeyerov 7y ago
  Re:Branching, having lived this, monorepos are very much a blessing, not a curse. If software is big enough to force considering monorepos, then cross-cutting dependencies will happen, and then one diffable long-lived monobranch is much better than a bunch of interleaved ones. Incrementally building, landing, etc., cross-cutting deps becomes much less of a slog. Ex: skip concerns about versioning of _internal_ APIs. The other issue I had was the sleight-of-hand on build modules. Yes, you don't need good devs to speed up incremental builds b/c you can search/build in each project. But if you want to run 20 modules together to test/experience them, good luck, esp. for interactive modes. (Congrats, you reinvented the monorepo!)
madhadron 7y ago
> There are few organizations that have so much code they break available source control solutions but simultaneously don't have the technical expertise to manage a monorepo that large. Facebook's Mononoke (https://github.com/facebookexperimental/mononoke https://github.com/facebookexperimental/mononoke) pretty much removes that argument. They outgrew their current source control, and that's their path forward for the next couple orders of magnitude.
- tiglionabbit 7y ago
  Not sure what you're implying about mononoke but the readme says: > The version that we provide on GitHub does not build yet. So, maybe eventually. They found that Git didn't do well at their scale, so they modified mercurial instead. I'm all in favor of a company-wide mono-repo if it doesn't have scaling issues.
  - sally1620 7y ago
    Most of monorepo tools for Mercurial are upstreamed already and are available in a standard Mercurial install. I don't think anyone in this thread is CTO of a company size of Facebook. For a medium size company, you can easily use Mercurial or Perforce.
humanrebar 7y ago
> In most cases I'd trade a little bit of modularity for increased domain logic consistency In my experience that is not the entire trade-off. At scale, you also get circular dependencies between modules, which makes refactoring, migrations, deprecations, and other improvements incrementally impossible. Sometimes this can happen unintentionally through including a "upcall" to a module that is actually the best tool for the local job at hand. In the case of several repos, you will notice the extra work needed to pull in the extra project. In the case of a monorepo... it might look like any benign change.

hashkb 7y ago

> We've developed lots of tools of strategies so we don't have to rely on people getting it right every time. I think one of the points of the article is that this isn't (sufficiently) true; people will use tools incorrectly and make excuses for deviating from the strategy often enough that it's a problem. > Ugh I don't like his use of the word dumbass Substitute "well-meaning person who makes a totally understandable process mistake"

deleted 7y ago
[deleted]

bartread 7y ago

> cross repo edits were painful. We are moving to a mono-repo for this very reason. Debugging something where you had to make changes to multiple projects, wait for those changes to go through the build pipeline, pull in updated packages in projects that depended on them, then change those projects (and on), was a complete nightmare. We're a bit over halfway there (the most painful half) and I expect us to get the rest done sometime in the next 3 months or so. Not looking back. At all.

CannisterFlux 7y ago

The branching example is very tempting when you have a product that is used on site by multiple customers. Customer A asks for some change that impacts customer B. Without good tests the easiest thing to do is fork the world for A and B, so the changes only impact one. Then you gradually drift apart. Add customer C, D, E... and it gets really fun. With multiple repos it gets even crazier. You have forks for A and B that work with some other software repo, maybe common, maybe forked itself. Soon you have wiki pages with compatibility matrices, common libraries that mysteriously break with minor changes despite being battle tested ... for some set of versions.

lmeyerov 7y ago
Re:Branching, having lived this, monorepos are very much a blessing, not a curse. If software is big enough to force considering monorepos, then cross-cutting dependencies will happen, and then one diffable long-lived monobranch is much better than a bunch of interleaved ones. Incrementally building, landing, etc., cross-cutting deps becomes much less of a slog. Ex: skip concerns about versioning of _internal_ APIs. The other issue I had was the sleight-of-hand on build modules. Yes, you don't need good devs to speed up incremental builds b/c you can search/build in each project. But if you want to run 20 modules together to test/experience them, good luck, esp. for interactive modes. (Congrats, you reinvented the monorepo!)

madhadron 7y ago

> There are few organizations that have so much code they break available source control solutions but simultaneously don't have the technical expertise to manage a monorepo that large. Facebook's Mononoke (https://github.com/facebookexperimental/mononoke https://github.com/facebookexperimental/mononoke) pretty much removes that argument. They outgrew their current source control, and that's their path forward for the next couple orders of magnitude.

tiglionabbit 7y ago
Not sure what you're implying about mononoke but the readme says: > The version that we provide on GitHub does not build yet. So, maybe eventually. They found that Git didn't do well at their scale, so they modified mercurial instead. I'm all in favor of a company-wide mono-repo if it doesn't have scaling issues.
- sally1620 7y ago
  Most of monorepo tools for Mercurial are upstreamed already and are available in a standard Mercurial install. I don't think anyone in this thread is CTO of a company size of Facebook. For a medium size company, you can easily use Mercurial or Perforce.

humanrebar 7y ago

> In most cases I'd trade a little bit of modularity for increased domain logic consistency In my experience that is not the entire trade-off. At scale, you also get circular dependencies between modules, which makes refactoring, migrations, deprecations, and other improvements incrementally impossible. Sometimes this can happen unintentionally through including a "upcall" to a module that is actually the best tool for the local job at hand. In the case of several repos, you will notice the extra work needed to pull in the extra project. In the case of a monorepo... it might look like any benign change.