Advantages of monolithic version control
danluu.com
Advantages of monolithic version control
1–10 of 144 posts
Re: Advantages of monolithic version control
#2I warmed up to the monorepo awhile ago but tooling and reference material that helps guide an org into adopting a monorepo and using it properly is hard to find.
Re: Advantages of monolithic version control
#3I initially found the idea of monolithic repositories hard to digest. But now I think it's a good idea for some of the reasons outlined in the article. Namely, it's very easy to depend on other code that the organization has created.
In the open source world, I have found some Unix distros use the same model. I know it's not as extreme, but the principle is quite similar. For example, in Nixpkgs all package definitions (which are actually code in the functional language Nix) are in the same repository and thus they can all depend on each other in a very easy and transparent way.
Re: Advantages of monolithic version control
#4I'm supportive of this approach; it's been an interesting shift from "multirepo". I think an advantage does come when a common language is used for projects, which is what I am familiar with. It can make it easier to enforce design patterns and re-use common code/dependencies (grep, text search, etc all in the same place that you're working in); which I think has a large positive effect on "loading working context" for whatever project you are working on - when there are common phrases and patterns and libraries used, it is easier to discuss with or to get advice from co-workers.
Re: Advantages of monolithic version control
#5I initially found the idea of monolithic repositories hard to digest. But now I think it's a good idea for some of the reasons outlined in the article. Namely, it's very easy to depend on other code that the organization has created. In the open source world, I have found some Unix distros use the same model. I know it's not as extreme, but the principle is quite similar. For example, in Nixpkgs all package definitio…
I initially found the idea of monolithic repositories hard to digest. But now I think it's a good idea for some of the reasons outlined in the article. Namely, it's very easy to depend on other code that the organization has created.
I remember the days when monorepo was the norm, and distributed version control was the weird, kooky idea. Mainstream programmers had knee-jerk notions that all managed environments were too slow.
For game development, monorepo is simpler. If one is using git, one needs to use some other software to turn the part of your repository for media into a monorepo, otherwise the asset files become a burden. (gitannex, for example)
Re: Advantages of monolithic version control
#6On the other end of the spectrum, a colleague of mine recently told me about when his previous company (big, 100k+ employees) were starting to adopt git, some people seriously considered having a separate repository per file! "Because then you can just set up your project as using version X of file A and version Y of file B"
It's good we now have (at least) Google, Facebook and Microsoft as examples of companies using monorepos. Those are names that carry some weight when thrown into a conversation.
Re: Advantages of monolithic version control
#7I initially found the idea of monolithic repositories hard to digest. But now I think it's a good idea for some of the reasons outlined in the article. Namely, it's very easy to depend on other code that the organization has created. In the open source world, I have found some Unix distros use the same model. I know it's not as extreme, but the principle is quite similar. For example, in Nixpkgs all package definitio…
> Namely, it's very easy to depend on other code that the organization has created.
On the other hand, I've seen the other sides of this in monorepos:
1. It's too easy to depend on code, so there is dependency bloat when something simpler would work just as well.
2. It's relatively hard to depend on things not in the repo, reinforcing not-invented-here culture.
Re: Advantages of monolithic version control
#8On the other end of the spectrum, a colleague of mine recently told me about when his previous company (big, 100k+ employees) were starting to adopt git, some people seriously considered having a separate repository per file ! "Because then you can just set up your project as using version X of file A and version Y of file B" It's good we now have (at least) Google, Facebook and Microsoft as examples of companies usi…
Google, Facebook, and Microsoft also make significant investments in tooling to get their monorepos to work. Picking a good package manager (or artifact repository) and making it a part company culture could be less work, depending on the context.
Re: Advantages of monolithic version control
#9I didn't notice a link to "Software Engineering at Google" which is a great article that goes into the monorepo argument as well as a lot of other cool practices.
Re: Advantages of monolithic version control
#10I warmed up to the monorepo awhile ago but tooling and reference material that helps guide an org into adopting a monorepo and using it properly is hard to find.
People always talk about how it takes all this tooling to have an effective monorepo— it definitely does; many moons ago I was a Googler too and experienced all the fun little perforce wrappers that would check out the portions of the tree you needed to build whatever it was you were trying to build.
But having things split across many repos also takes a lot of tooling too. So really, for each approach you're looking at which portions of it are covered by the version control system itself, and where the gaps are that have to be plugged by auxiliary stuff. And of the auxiliary stuff, how much of it is standard enough to be things you can inherit pretty much off the shelf from your distro or other ecosystem vs. something you need to actually build and maintain in-house.
Other organizational priorities come into play too, like the importance of open source in your codebase, and what your relationships are to your upstreams, if you have them. It actually surprises me that there aren't more/better tools out there that help with synchronizing commits (or portions of commits) in and out of external standalone repos. The main patch-management tool I'm aware of is Debian's quilt, which pretty much just boils down to a handful of bash scripts and arcane conventions. Why isn't there more stuff in this space?