5 ms·

I worked in a company that had at least 100 repos, often with interdependencies, and was managing it well using svn. Then we migrated to Git, which doesn't hav

I worked in a company that had at least 100 repos, often with interdependencies, and was managing it well using svn. Then we migrated to Git, which doesn't have a good equivalent to svn's externals, and things kind of went to heck for a while. We eventually hacked together an in-house system that brought back some of what we were missing, but it never worked as smoothly as svn externals did. I was originally one of the advocates of moving to Git. Hindsight being 20/20, after the dust settled I realized we would have been fine staying on svn, anyway. With such a high number of individual repositories, blocking on each other and nasty merge conflicts were rarely a problem in practice because we had over 100 swim lanes clearly marked in the pool. Lots more swim lanes than we had developers. FWIW, one team dealt with it by migrating just their stuff to their own monorepo, and I wasn't too impressed by that outcome, either. They started seeing an outsize rate of technical debt accumulation as things that previously were easier to keep well modularized started naturally getting more tangled together. I realize that is a problem that can easily be managed with just a little effort. But, like every other dev problem that can easily be managed with just a little effort, it wasn't.

pierrebai 7y ago
git has submodules. A repo can thus host any number of sub-repos. Using modules can also be pretty much like having a monorepo if you have a master repo with all others under it. This way, you can still publish things like public API as a repo.
- mumblemumble 7y ago
  They don't work quite the same way as svn externals, though, in a way that didn't work for us. In particular, they leave no good way to deal with merging in upstream changes in a submodule's code if you've also made some of your own (provisional) edits.
- mceachen 7y ago
  Submodules don't allow for atomic commits that span repos, though. Atomic cross-project commits are the most compelling selling feature for monorepos IMHO. (A common case for this is changing a function's API, and fixing all downstream consumers, in one tidy, holistic PR).
  - JoshTriplett 7y ago
    > Submodules don't allow for atomic commits that span repos, though. They can, but there's little tooling support to help you do so. You can make a new commit in one repo, and then in one atomic commit, you can pull that new commit into a parent repo's submodule and fix the users calling into that submodule.

pierrebai 7y ago

git has submodules. A repo can thus host any number of sub-repos. Using modules can also be pretty much like having a monorepo if you have a master repo with all others under it. This way, you can still publish things like public API as a repo.

mumblemumble 7y ago
They don't work quite the same way as svn externals, though, in a way that didn't work for us. In particular, they leave no good way to deal with merging in upstream changes in a submodule's code if you've also made some of your own (provisional) edits.
mceachen 7y ago
Submodules don't allow for atomic commits that span repos, though. Atomic cross-project commits are the most compelling selling feature for monorepos IMHO. (A common case for this is changing a function's API, and fixing all downstream consumers, in one tidy, holistic PR).
- JoshTriplett 7y ago
  > Submodules don't allow for atomic commits that span repos, though. They can, but there's little tooling support to help you do so. You can make a new commit in one repo, and then in one atomic commit, you can pull that new commit into a parent repo's submodule and fix the users calling into that submodule.