3 ms·

I will get a furry of downvotes for saying it but the cause of your first three problems is git, not the mono repo approach. Git only allows to check/commit/vi

I will get a furry of downvotes for saying it but the cause of your first three problems is git, not the mono repo approach. Git only allows to check/commit/view to the entire repo at once. Then, some git operations are superlinear with the number of files or revisions, they are slow on large repo to the point of being unusable. It's mandatory to have operation on a per file or subdirectory level in a mono repo approach. Companies that have mono repos all built tooling to support it. CVS/SVN used to do that out of the box but everyone hate them now.

k__ 9y ago
Why aren't submodules more wide spread? Building a monorepo out of submodules should solve these problems, or not? Also, there is subtree.
- iveqy 9y ago
  Because submodules is hard to understand. They require that you understand git and that you can add one level of abstraktion. Once you done that, they är great!
  - Groxx 9y ago
    Also hard to deal with. Lots of operations leave submodules in unclean / out-of-date states. In general / light use, yeah, they're great. Unfortunately, they have a very large number of edge cases where they essentially require either a) everyone to be experts in the edge cases, or b) tons of new tooling (because existing tools won't take these steps for you).
  - lamlam 9y ago
    That is... until you try to remove a submodule. I like sobmodules, but the whole feature needs a lot more polish before it's widely adopted.
svckr 9y ago
> CSV/SVN used to do that out of the box but everyone hate them now. It's "CVS" and it lacks a concept for a repository-wide version (except, maybe, a timestamp). A repository-wide version is –I guess– the single best reason to have monorepo in the first place. SVN is okay. Also, `git log -- subdir/`.
nickm12 9y ago
That's fair. I think the important thing is to be able to have multiple versions of portions of your repo and then be able to version that. A branch of branches, so to speak.

k__ 9y ago

Why aren't submodules more wide spread? Building a monorepo out of submodules should solve these problems, or not? Also, there is subtree.

iveqy 9y ago
Because submodules is hard to understand. They require that you understand git and that you can add one level of abstraktion. Once you done that, they är great!
- Groxx 9y ago
  Also hard to deal with. Lots of operations leave submodules in unclean / out-of-date states. In general / light use, yeah, they're great. Unfortunately, they have a very large number of edge cases where they essentially require either a) everyone to be experts in the edge cases, or b) tons of new tooling (because existing tools won't take these steps for you).
- lamlam 9y ago
  That is... until you try to remove a submodule. I like sobmodules, but the whole feature needs a lot more polish before it's widely adopted.

svckr 9y ago

> CSV/SVN used to do that out of the box but everyone hate them now. It's "CVS" and it lacks a concept for a repository-wide version (except, maybe, a timestamp). A repository-wide version is –I guess– the single best reason to have monorepo in the first place. SVN is okay. Also, `git log -- subdir/`.

nickm12 9y ago

That's fair. I think the important thing is to be able to have multiple versions of portions of your repo and then be able to version that. A branch of branches, so to speak.