91–100 of 159 posts
Earlier quoted context omitted.
I asked a similar question a previous time the mono- vs many- repo question came out, and the few responses I got were roughly "The repo became many tens of gigabytes which was unwieldy"
Unfortunately, breaking a 10 gig repo into 5 repos often means you have to now download five 2 gig repos.
> the entire code base got forked, and the entire org is now held hostage by the dumbass. > Of course in a Good team, needless dependencies would be weeded out in code reviews, and a Culture would evolve over time avoiding needless dependencies. Really, the one consistent thing is that if you have a good team, you'll make it work no matter what tech or decisions you make (assuming you're also good enough to know when…
>> Of course in a Good team, needless dependencies would be weeded out in code reviews, and a Culture would evolve over time avoiding needless dependencies. Heh. This reminded me of a different story, which I remember vaguely enough that I'll paraphrase from memory: > "The Excel team will never go for it. Their motto is 'Find the dependencies... and eliminate them.'" > This probably explained why the Excel team had i…
Earlier quoted context omitted.
Please note that Linus wrote an operating system that in practice showed greater reliability than competing commercial microkernels. I do not believe that the principles that he came to believe in that process should be dismissed as straw man arguments.
Tell that to my (lack of) graphics drivers. You can say its political but as it stands its no where near apples to apples in terms of what Windows supports vs what Linux supports.
I am of course including supercomputers, embedded hardware, and hand-held phones. Admittedly Windows has greater support for is running consumer hardware for desktops. But that has to do with how small the Linux marketshare is. And is hardly an indictment of Linus' work.
The drawback is that not many people are familiar with submodules and they can be a bit tedious to set up, though working with a submodule is almost like working with a normal file in git. One danger is of course that branching between individual submodules can get messy. Another nuisance might be that you have to commit recursively, i.e. if you have one repository with a submodule to which you make changes you need to first commit these changes in the submodule and then create a new commit in the parent repository that adds the new version of the submodule. Maybe this is a good thing though as it forces you to commit changes individually in each submodule before committing a larger change into your main repository. In general I would avoid nesting submodules more than two levels deep, as this can quickly get confusing.
In the past I've also worked on a large mono-repositoriy and enjoyed it as well, just curious to hear if anybody has used submodules in a larger team.
Earlier quoted context omitted.
>> Of course in a Good team, needless dependencies would be weeded out in code reviews, and a Culture would evolve over time avoiding needless dependencies. Heh. This reminded me of a different story, which I remember vaguely enough that I'll paraphrase from memory: > "The Excel team will never go for it. Their motto is 'Find the dependencies... and eliminate them.'" > This probably explained why the Excel team had i…
Sounds like Joel on Software.
Does anybody know some monorepo horror stories? I have heard plenty of people complain about their many-repo structure and wishing for a monorepo. I would like to hear some concrete story where a monorepo went wrong. This article is just abstract opinion.
Oh yes. #1 problem I've experienced at multiple places: delaying integration with tons of branching. Usually the PM or PO force everyones to using some vague "product version" they track for public releases. Places that use monorepos well tend to have very few branches (like, maybe 2 or 3), which have nothing to do with your public product versioning scheme, and instead use "branch by abstraction" to stay integrated.…
Does anyone here have experience using submodules to tie individual repositories together? We've been using this in our small startup (only a few developers) and so far it works nicely. It allows us to check out and develop repositories individually but at the same time maintain an exact dependency graph for our entire system. You can for example have a single repository that ties together different projects and has…
Earlier quoted context omitted.
Tell that to my (lack of) graphics drivers. You can say its political but as it stands its no where near apples to apples in terms of what Windows supports vs what Linux supports.
And yet somehow Linux manages to run on a greater variety of hardware than Windows does. I am of course including supercomputers, embedded hardware, and hand-held phones. Admittedly Windows has greater support for is running consumer hardware for desktops. But that has to do with how small the Linux marketshare is. And is hardly an indictment of Linus' work.
Does anyone here have experience using submodules to tie individual repositories together? We've been using this in our small startup (only a few developers) and so far it works nicely. It allows us to check out and develop repositories individually but at the same time maintain an exact dependency graph for our entire system. You can for example have a single repository that ties together different projects and has…
As you say, getting a change first into the child and then into the parent requires double PRs and testing. But that's the same as if you had it as a package dependency. Only that instead of a version, you have a sha1 which you never know what it is.
I prefer package dependency, because it forces you to explicitly make a release, where it should have passed PR and some integration tests. Also merge conflicts are clearer.
Is the monorepo/multirepo choice really the most important thing to consider? Branching: monorepo or not, if a feature-incomplete development branch for one of the supported targets can "hold the entire organization as a hostage" then the SCM people, and/or persons responsible of the SCM policy, should do some introspection... Why are deliveries done from a branch which is obviously still in development? Why does cod…
Formally speaking, multi-repo management allows a strict subset of the diffs allowed to a mono-repo (because diffs can 't extend beyond each repo root). Are the excluded possibilities all bad? No. Are they generally bad? Not really. Are they sometimes bad? Sure. Are they sometimes better than many diffs across many repos? Sure. Can a reasonably competent dev team tell the difference? Sure, usually. Unsurprisingly, this usually requires the exact same tooling as ensuring the quality of microrepo changes.
If you're continuously deploying master, have a healthy ci/cd pipeline, and enforce good merging discipline, you're fine either way.
I'm a little tired of doing things like revving our trace and logging libraries across our 50+ micro repos that represent microservices. That's genuinely obnoxious. Is it bad? No. Is it obviously more or less error prone than the equivalent monorepo update? No. All the bad bits of either strategy just require some tooling and a clear head.