4 ms·

Repo style wars: mono vs. multi

30 points by zeveb 9y ago

luckydude 9y ago
The premise put forth in this article is only true for loosely coupled subrepos, like git's submodule hack. BitKeeper has had atomic commits and the same lock step guarantees of a monorepo for years. Opensource and everything. http://www.bitkeeper.org http://www.bitkeeper.org http://www.mcvoy.com/lm/bkdocs/nested.html http://www.mcvoy.com/lm/bkdocs/nested.html
- glandium 9y ago
  At the low level, git submodules provide atomic commits too. The UX is "just" too limited.
  - luckydude 9y ago
    No they don't. If you have a commit that spans the top repo and 3 submodules and you try do all that and something goes wrong, does git roll it back to where you were? Nope. In BK, with nested repos, we talk a cluster wide lock, which locks the top repo and all the subrepos, and then we go do the commits in all the subrepos and then in the top. If anything goes wrong we roll back to where we were. It's all or nothing, and atomic across the collect. Please read the nested link I provided. It's nothing like git. It works in a nested collection of subrepos exactly how a mono repo works. Git has nothing like this.
Jyaif 9y ago
Very thorough and well balanced article. Congratulations. I'm still in the multi-repo camp for the following reasons: -It's true that in both case special tooling will eventually need to be created, but I think that special tooling that sits on top of VCS is easier than tooling that requires actually improving the VCS themselves. -The article mentions that in a mono repo allows you to more easily fix things yourself, but in practice you should not fix things yourself because you'll be slower and/or make more mistakes than the people that are experts in this area of the code. Making hard for any person to fix any random piece of the code is a feature of multi-repos. -"when reality dictates that things the used to be coupled should be decoupled or things that used to be decoupled need to be joined closer together" Again, making it hard to couple code together is a feature. -Re-usability of mono-repos is 0.
- zeveb 9y ago
  > The article mentions that in a mono repo allows you to more easily fix things yourself, but in practice you should not fix things yourself because you'll be slower and/or make more mistakes than the people that are experts in this area of the code. Making hard for any person to fix any random piece of the code is a feature of multi-repos. I disagree: nothing's worse than when someone changes one of my dependencies. I know nothing about his API or why he changed it, and now I have to figure out what he did and why. In a professional organisation, the cost of a change should be borne by the one making it, not by others. I shouldn't be able to hold another team back by pursuing my bliss.
igor47 9y ago
The article fails to discuss the ever-popular lots-o-monorepos approach ;) I really liked the idea behind the approach I learned from the linked-in tools team: project-oriented build-test-deploy tooling. In this approach, it doesn't matter how the projects map to repos. instead, the tooling specifies a canonical way to declare projects (including owners) and their dependencies. The build tool takes care of placing the dependencies in the project build environment, and enforces versioning (like if a library author needs to yank a version because of a bug). This approach lets library authors make changes without having to update all use cases. They still get to yank versions and test new versions against all use cases in an infra. The project owners get control of their dependencies -- they get to choose what to use and when to build and deploy updates, but also can't fall hopelessly behind on updates -- the build tool won't let them, and they can see which dependencies need updates. My favorite part is that the build tool can be used for both internal and external dependencies -- who works on them or where they're stored is irrelevant. I haven't had a chance to implement this approach, but it sounds promising. I also like the migration path -- most companies should probably start with multiple repos to take advantage of open-source and hosted tooling, and this approach allows incremental migration to get advantages of mono-repo without a painful all-or-nothing migration.

30 points by zeveb 9y ago

The premise put forth in this article is only true for loosely coupled subrepos, like git's submodule hack. BitKeeper has had atomic commits and the same lock step guarantees of a monorepo for years. Opensource and everything. http://www.bitkeeper.org http://www.bitkeeper.org http://www.mcvoy.com/lm/bkdocs/nested.html http://www.mcvoy.com/lm/bkdocs/nested.html

glandium 9y ago
At the low level, git submodules provide atomic commits too. The UX is "just" too limited.
- luckydude 9y ago
  No they don't. If you have a commit that spans the top repo and 3 submodules and you try do all that and something goes wrong, does git roll it back to where you were? Nope. In BK, with nested repos, we talk a cluster wide lock, which locks the top repo and all the subrepos, and then we go do the commits in all the subrepos and then in the top. If anything goes wrong we roll back to where we were. It's all or nothing, and atomic across the collect. Please read the nested link I provided. It's nothing like git. It works in a nested collection of subrepos exactly how a mono repo works. Git has nothing like this.

Jyaif 9y ago

Very thorough and well balanced article. Congratulations. I'm still in the multi-repo camp for the following reasons: -It's true that in both case special tooling will eventually need to be created, but I think that special tooling that sits on top of VCS is easier than tooling that requires actually improving the VCS themselves. -The article mentions that in a mono repo allows you to more easily fix things yourself, but in practice you should not fix things yourself because you'll be slower and/or make more mistakes than the people that are experts in this area of the code. Making hard for any person to fix any random piece of the code is a feature of multi-repos. -"when reality dictates that things the used to be coupled should be decoupled or things that used to be decoupled need to be joined closer together" Again, making it hard to couple code together is a feature. -Re-usability of mono-repos is 0.

zeveb 9y ago
> The article mentions that in a mono repo allows you to more easily fix things yourself, but in practice you should not fix things yourself because you'll be slower and/or make more mistakes than the people that are experts in this area of the code. Making hard for any person to fix any random piece of the code is a feature of multi-repos. I disagree: nothing's worse than when someone changes one of my dependencies. I know nothing about his API or why he changed it, and now I have to figure out what he did and why. In a professional organisation, the cost of a change should be borne by the one making it, not by others. I shouldn't be able to hold another team back by pursuing my bliss.

igor47 9y ago

The article fails to discuss the ever-popular lots-o-monorepos approach ;) I really liked the idea behind the approach I learned from the linked-in tools team: project-oriented build-test-deploy tooling. In this approach, it doesn't matter how the projects map to repos. instead, the tooling specifies a canonical way to declare projects (including owners) and their dependencies. The build tool takes care of placing the dependencies in the project build environment, and enforces versioning (like if a library author needs to yank a version because of a bug). This approach lets library authors make changes without having to update all use cases. They still get to yank versions and test new versions against all use cases in an infra. The project owners get control of their dependencies -- they get to choose what to use and when to build and deploy updates, but also can't fall hopelessly behind on updates -- the build tool won't let them, and they can see which dependencies need updates. My favorite part is that the build tool can be used for both internal and external dependencies -- who works on them or where they're stored is irrelevant. I haven't had a chance to implement this approach, but it sounds promising. I also like the migration path -- most companies should probably start with multiple repos to take advantage of open-source and hosted tooling, and this approach allows incremental migration to get advantages of mono-repo without a painful all-or-nothing migration.