Repo style wars: mono vs. multi
gigamonkeys.com
gigamonkeys.com
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.
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.
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.
BitKeeper has had atomic commits and the same lock step guarantees of a monorepo for years.
Opensource and everything. http://www.bitkeeper.org
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.