
Repo style wars: mono vs. multi - zeveb
http://www.gigamonkeys.com/mono-vs-multi/
======
Jyaif
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
> 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
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.

------
luckydude
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
At the low level, git submodules provide atomic commits too. The UX is "just"
too limited.

~~~
luckydude
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.

