6 ms·

Of course, there are downsides to using a monorepo. I’m not going to discuss them because the downsides are already widely known and discussed. I searched but

Of course, there are downsides to using a monorepo. I’m not going to discuss them because the downsides are already widely known and discussed. I searched but I honestly can't find them. The only things I can think of are: implementation problems (repo too large, every git pull takes more time than strictly necessary for your project) and tainting tools like "git log". Those don't seem very fundamental. Solvable by a "monogit" wrapper, if someone put their mind to it. Or are they? Is there a fundamental problem I'm missing? I feel stupid for asking, given how matter of fact he dismissed it :( EDIT: I guess what I'm trying to say is: monorepos feel, theoretically, like a strict superset of many independent ones. It's just the tooling that makes it less convenient.

x1024 11y ago
"It's too slow" is not a trivial problem to solve. Anything but. At some large companies the simple act of making a commit takes the better part of an hour. Same with checking out, updating, etc. This has serious implications for the development style and productivity. At the very least, not every developer can adapt to such a style.
- gecko 11y ago
  "It's too slow" is not a trivial problem to solve. Anything but. Depends on your viewpoint, but I'd argue it's not actually that hard to solve unless you also require you solve it within the context of Git. For example, in most systems, you can do something called a narrow checkout, where you only grab part of the tree of the whole repository. Subversion, Monotone, Perforce, and (soon) Mercurial all support this, whereas Git does not--and, the last I looked at the Git protocol, it wouldn't have been sane to implement. (Been about two years at this point, so I apologize if that has changed.) Beyond that, even local commit in a single repo is actually pretty easy to solve if you have file watchers (powered by e.g. inotify, kqueue), which at least Mercurial does, and I'd honestly swear Git does also. At that point, I don't think there's a lot left that inherently has to make commits take the better part of an hour. If you are at such a company, please take a moment to run strace or something; I'm really curious where the tool's spending so much time.
  - harkyns_castle 11y ago
    > whereas Git does not [...] Git's "sparse checkout" feature can grab a part of a larger repo from memory.
  - jfreax 11y ago
    Just as an update for you: You can do "shallow" clones in git (clone up to a maximum given depth of history). Since Version 1.9 (released early 2014), you can use such a repo like a normal one (push, clone from it, ...)
    - gecko 11y ago
      Shallow is not narrow, and I specifically meant narrow in this particular context. A narrow clone gives you the full history for part of the tree.
blackaspen 11y ago
The speed is a serious downside. Go on vacation for two weeks? You get to go on another vacation while you wait for your monorepo to update. Similarly, good luck ever trying to work from a coffee shop -- at the very least you probably have 50mb of updates because everyone in the company is committing code all the time.
- gecko 11y ago
  This is only true if you do two unrelated things simultaneously: have a monolithic repo, and keep the whole thing checked out at all times. Provided you have a sane build system (pants, Blaze, Buck, etc.), then the only thing that should need to have the full checkout is the CI server; you should be able to safely work from a narrow clone. That said, I find your note a bit amusing. I'd have agreed a decade ago, but nowadays, 50 MB should take effectively zero time for you to both download and apply. It's worth revisiting things like this as LANs and the internet get faster; I think the speed comment is a bit outdated now.
  - blackaspen 11y ago
    True, however Pants right now does not have support with Git to only checkout dependencies it actually needs for the build. I agree that it should take effectively zero time for me to download and apply 50MB of updates, but poor quality internet is still pretty easy to find (working with plane wifi) -- maybe my coffee shops have worse internet than yours!
- VikingCoder 11y ago
  > You get to go on another vacation while you wait for your monorepo to update. If you care, you should read about how Google makes sure this doesn't happen. > By putting our revision history in the cloud we provide engineers with complete access to all the source, and yet almost no time is spent checking out code. http://google-engtools.blogspot.com/2011/06/build-in-cloud-accessing-source-code.html http://google-engtools.blogspot.com/2011/06/build-in-cloud-a... http://google-engtools.blogspot.com/2011/08/build-in-cloud-how-build-system-works.html http://google-engtools.blogspot.com/2011/08/build-in-cloud-h...
- 11y ago
bazzargh 11y ago
Permissions? ie different teams with different push/pull rights for different repositories. We have that where I work; for most projects it seems like needless complexity, but some things are more closely controlled; payment handling, ops (where a change could bring down the whole org not just an app), etc. There's also the issue of contractors being brought in, generally they see a restricted subset of the codebase.
- daxelrod 11y ago
  A lot of the VCSes that use the monorepo model allow fine grained permissions on various parts of the repo (this necessitates being able to restrictively fetch only part of the repo).
clux 11y ago
Biggest problem is also its greatest benefit. If everything CAN access anything, everything WILL eventually access anything. Without any barriers, it's way too easy for things to devolve into spaghetti code.
- theCodeStig 11y ago
  This exactly.

x1024 11y ago

"It's too slow" is not a trivial problem to solve. Anything but. At some large companies the simple act of making a commit takes the better part of an hour. Same with checking out, updating, etc. This has serious implications for the development style and productivity. At the very least, not every developer can adapt to such a style.

gecko 11y ago
"It's too slow" is not a trivial problem to solve. Anything but. Depends on your viewpoint, but I'd argue it's not actually that hard to solve unless you also require you solve it within the context of Git. For example, in most systems, you can do something called a narrow checkout, where you only grab part of the tree of the whole repository. Subversion, Monotone, Perforce, and (soon) Mercurial all support this, whereas Git does not--and, the last I looked at the Git protocol, it wouldn't have been sane to implement. (Been about two years at this point, so I apologize if that has changed.) Beyond that, even local commit in a single repo is actually pretty easy to solve if you have file watchers (powered by e.g. inotify, kqueue), which at least Mercurial does, and I'd honestly swear Git does also. At that point, I don't think there's a lot left that inherently has to make commits take the better part of an hour. If you are at such a company, please take a moment to run strace or something; I'm really curious where the tool's spending so much time.
- harkyns_castle 11y ago
  > whereas Git does not [...] Git's "sparse checkout" feature can grab a part of a larger repo from memory.
- jfreax 11y ago
  Just as an update for you: You can do "shallow" clones in git (clone up to a maximum given depth of history). Since Version 1.9 (released early 2014), you can use such a repo like a normal one (push, clone from it, ...)
  - gecko 11y ago
    Shallow is not narrow, and I specifically meant narrow in this particular context. A narrow clone gives you the full history for part of the tree.

blackaspen 11y ago

The speed is a serious downside. Go on vacation for two weeks? You get to go on another vacation while you wait for your monorepo to update. Similarly, good luck ever trying to work from a coffee shop -- at the very least you probably have 50mb of updates because everyone in the company is committing code all the time.

gecko 11y ago
This is only true if you do two unrelated things simultaneously: have a monolithic repo, and keep the whole thing checked out at all times. Provided you have a sane build system (pants, Blaze, Buck, etc.), then the only thing that should need to have the full checkout is the CI server; you should be able to safely work from a narrow clone. That said, I find your note a bit amusing. I'd have agreed a decade ago, but nowadays, 50 MB should take effectively zero time for you to both download and apply. It's worth revisiting things like this as LANs and the internet get faster; I think the speed comment is a bit outdated now.
- blackaspen 11y ago
  True, however Pants right now does not have support with Git to only checkout dependencies it actually needs for the build. I agree that it should take effectively zero time for me to download and apply 50MB of updates, but poor quality internet is still pretty easy to find (working with plane wifi) -- maybe my coffee shops have worse internet than yours!
VikingCoder 11y ago
> You get to go on another vacation while you wait for your monorepo to update. If you care, you should read about how Google makes sure this doesn't happen. > By putting our revision history in the cloud we provide engineers with complete access to all the source, and yet almost no time is spent checking out code. http://google-engtools.blogspot.com/2011/06/build-in-cloud-accessing-source-code.html http://google-engtools.blogspot.com/2011/06/build-in-cloud-a... http://google-engtools.blogspot.com/2011/08/build-in-cloud-how-build-system-works.html http://google-engtools.blogspot.com/2011/08/build-in-cloud-h...
11y ago

bazzargh 11y ago

Permissions? ie different teams with different push/pull rights for different repositories. We have that where I work; for most projects it seems like needless complexity, but some things are more closely controlled; payment handling, ops (where a change could bring down the whole org not just an app), etc. There's also the issue of contractors being brought in, generally they see a restricted subset of the codebase.

daxelrod 11y ago
A lot of the VCSes that use the monorepo model allow fine grained permissions on various parts of the repo (this necessitates being able to restrictively fetch only part of the repo).

clux 11y ago

Biggest problem is also its greatest benefit. If everything CAN access anything, everything WILL eventually access anything. Without any barriers, it's way too easy for things to devolve into spaghetti code.

theCodeStig 11y ago
This exactly.