On: Repo style wars: mono vs. multi

[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.mcvoy.com/lm/bkdocs/nested.html

[glandium → luckydude]

At the low level, git submodules provide atomic commits too. The UX is "just" too limited.

[luckydude → glandium]

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.