21–30 of 103 posts
After working on a monorepo and then the split up repos for the same codebase, I cannot fathom why somebody would want to take small repos and merge them in a single repo. The mess and complexity just increase.
For me, I prefer git submodules, which seem to have the benefit of both monorepo and separate repo's.
Big corporations are extremely inefficient. Why does everyone want to copy them? And why do we use all the bulky tools they produce when there are far simpler, better and more open alternatives available?
Because it turns out big corporations that use multirepos tend to be even less efficient (about versioning) than those that use monorepos. What are those far simpler, better, more open alternatives?
Amazon disagrees.
In the last few years, I saw a lot of people using monorepos, and discouraging using submodules. Frankly, I don't know why. For small projects, sure - it it an overhead. For anything larger, I find it useful to encapsulate things - be it installable packages, or if it is not the case - at least other repositories. In the last months I split one project into 4 repos ( https://github.com/Quantum-Game/ ) and couldn't be…
Moving to mono repos has been great for my team for reducing build times and removing the overhead of understanding decades of cruft built up to make a huge mono repo manageable.
But with turnover of both projects and people, and many projects not requiring active development, there's an awful lot of orphaned repos, with less than one person dedicated supporting them now.
In my environment at least, you can just stop development. Packages need to be kept up to date, as vulnerabilities are discovered, using Azure Devops means we need to move along with changes to the build process. Infrastructure and Secrets policies changes come from outside, and require us to make changes.
Making these kind of changes to a handful of repos is quite a bit of overhead. It's clear now, we went too small on the repo size, given the tools we have for the maintenance tasks we have to do.
And people advocate for even smaller repos...
In the last few years, I saw a lot of people using monorepos, and discouraging using submodules. Frankly, I don't know why. For small projects, sure - it it an overhead. For anything larger, I find it useful to encapsulate things - be it installable packages, or if it is not the case - at least other repositories. In the last months I split one project into 4 repos ( https://github.com/Quantum-Game/ ) and couldn't be…
The benefits of monorepos are (IME) all in people and organisation scale. For example, I've found it orders of magnitude easier to align tooling, quality, release and standards on a monorepo with 100's of 1000's of engineers working on it simultaneously. The point you've made is a good one though, the idea of monorepos at small scale has come up a lot recently and I'm not sure the arguments for it are as compelling (…
Earlier quoted context omitted.
Because it turns out big corporations that use multirepos tend to be even less efficient (about versioning) than those that use monorepos. What are those far simpler, better, more open alternatives?
> Because it turns out big corporations that use multirepos tend to be even less efficient (about versioning) than those that use monorepos. How do you measure that exactly?
Google and Microsoft have both evaluated this internally and reached that conclusion, with some of the evaluation criteria and conclusions publicly documented (though I don’t have links available on my phone, google will likely find them for you)
After working on a monorepo and then the split up repos for the same codebase, I cannot fathom why somebody would want to take small repos and merge them in a single repo. The mess and complexity just increase.
4 or 5 repos would probably have been sane. 130 was hell to manage.
After working on a monorepo and then the split up repos for the same codebase, I cannot fathom why somebody would want to take small repos and merge them in a single repo. The mess and complexity just increase.
With a monorepo, you can always check out a consistent version of all parts.
After working on a monorepo and then the split up repos for the same codebase, I cannot fathom why somebody would want to take small repos and merge them in a single repo. The mess and complexity just increase.
In git I fully agree, and I wonder which company successfully runs a monorepo in git. For me, I prefer git submodules, which seem to have the benefit of both monorepo and separate repo's.
Microsoft
What is the advantage over using `git subtree`?