The main driver of success in either model is in the tooling and practices invested in it to make it work in an organization. Google is successful with their monorepo because they have invested in building (blaze), source control (piper, code search), and commit to always developing on HEAD. Multirepo is currently easier for most companies because most public tooling (git, package manager) is built around multirepos. One place I see multirepos fall over is awful dependency management practices internally and in open source. Many dependencies quickly become outdated and are not updated in cadence, slowing down writers and consumers. Better tooling can help here but an organization needs real discipline to stay on top of things.
I’m using mu-repo, which I think is a nice compromise. You put all the git repos you need into a root folder, ‘register’ them with mu, and then you can use mu as a replacement for the git command. E.g. mu commit -m "msg" would do a git commit for every repo that has changes. The nice thing is that you can still treat every git repo as before, if that is appropriate. Also, you can just add ‘forked’ dependency repos the same way, the structure is not fixed, like it would be with a monorepo.
Might not be a viable solution for really big monorepos, but I’m quite happy with the solution for the requirements I have.
Git VFS gets your repo size from a handful of GB to a few hundred GB. Nobody knows if it scales further.
I wonder how such big repositories deal with other aspects like a huge number of branches and tags. Also, the lack of fine grained access control is not solved afaik. Did they consider a switch to Subversion?
Im not sure who you are talking about here, Google has there own custom source control system [1] and Facebook is investing in improving mercurial currently. Google created the concept of the CODEOWNERS file for access control which GitHub ended up implementing. Microsoft is committed to scaling Git through VFS because of the GitHub acquisition.
The main driver of success in either model is in the tooling and practices invested in it to make it work in an organization. Google is successful with their monorepo because they have invested in building (blaze), source control (piper, code search), and commit to always developing on HEAD. Multirepo is currently easier for most companies because most public tooling (git, package manager) is built around multirepos. One place I see multirepos fall over is awful dependency management practices internally and in open source. Many dependencies quickly become outdated and are not updated in cadence, slowing down writers and consumers. Better tooling can help here but an organization needs real discipline to stay on top of things.
I was surprised to not see Lerna or yarn workspaces mentioned at all.
I’m using mu-repo, which I think is a nice compromise. You put all the git repos you need into a root folder, ‘register’ them with
mu, and then you can usemuas a replacement for thegitcommand. E.g.mu commit -m "msg"would do agit commitfor every repo that has changes. The nice thing is that you can still treat every git repo as before, if that is appropriate. Also, you can just add ‘forked’ dependency repos the same way, the structure is not fixed, like it would be with a monorepo.Might not be a viable solution for really big monorepos, but I’m quite happy with the solution for the requirements I have.
The shortcomings of monorepo is not about the concept but about using git for that.
Git virtual file system should make
gitviable, especially as GitHub implements it. I thinkgithas mechanisms for partial repo checkout, unsure.Git VFS gets your repo size from a handful of GB to a few hundred GB. Nobody knows if it scales further.
I wonder how such big repositories deal with other aspects like a huge number of branches and tags. Also, the lack of fine grained access control is not solved afaik. Did they consider a switch to Subversion?
Im not sure who you are talking about here, Google has there own custom source control system [1] and Facebook is investing in improving mercurial currently. Google created the concept of the CODEOWNERS file for access control which GitHub ended up implementing. Microsoft is committed to scaling Git through VFS because of the GitHub acquisition.
[1]