71–80 of 100 posts
Google posted a paper detailing their reasons for choosing monorepo: https://research.google/pubs/pub45424/ Caveat: your company probably isn't Google, so your challenges may be different.
Twitter: Monorepo Facebook: Monorepo Google: Monorepo Amazon: Multirepo Of these companies, compare AWS and the number of services, new features and quick turn around time with their competitors, and get back to me.
EDIT: that being said, I do think multirepo is better, but only when you have the above tools to manage it.
Earlier quoted context omitted.
> You have to figure out with every commit what actually changed and based on that change what needs to be tested and built. I feel this problem and I wonder, is there any ready-made solution for that?
We just build and test everything every time. Maybe it costs us more $$$ on CI, but it costs far less in developer time. That being said, I mostly work at startups and larger companies will certainly cross a threshold where this isn't feasible.
Nope. Worked at the largest US bank that happens to be mono repo. They had compute grids with thousands of cores running tests 24/7. It's not sizable compared to the costs of the developers writing and maintaining software.
Earlier quoted context omitted.
Git + Bazel will be fine for scaling up to 100s of engineers from my experience (at Lyft's L5 autonomous division). My other data point is Google, with 10,000s of engineers and a bespoke VCS. I'm not sure how things work in the middle (1000s of engineers), but I think you can solve that problem when you get to it, and Bazel has some features (look at the git_repository rule) to help you split a big repo if you need t…
I work in a project with 50 engineers. Our git repo is 2GB plus 5GB of submodules. Git is painfully slow and I would imagine with more engineers it would become unusable. For example, git-fetch takes at least a minute. To some degree we are doing it wrong like using Windows, creating too many tags, and committing binary blobs (despite LFS). Still, scaling it up by factor of two or three would not change it significan…
`du -sh repo` for me is 15GB, and we don't experience the slowness you describe. If I'm checking out a branch that diverged from master 1 year ago, it takes maybe... 30 seconds?
But I don't know, maybe we've cast different git-spells from you all? We don't use sub-modules, for example.
I won't try to be exhaustive here, but I think it's worth mentioning a few things: One con is that most open source (as well as publicly available but proprietary) tooling is geared towards the non-monorepo approach. So if you want to use a monorepo, you're going to have to fight a bit of an uphill battle because most tools and processes assume you have lots of little repos. For example, build triggers in a lot of CI…
Regression tests across multiple repos are still required. I don't see how splitting a monorepo into multiple repos gets rid of those tests.
We are breaking our monorepo into 3 kind-of mono repos based on release cadence. A repo for each of two large applications plus a third repo for shared library code. We import the share library code onto the app repos using a git sub module. Has anyone else used git sub-repos to import common code?
My gut tells me they should be separate, but I'm curious what other people think.
Earlier quoted context omitted.
> Churn from other dev's stuff gets in your merge/rebase work Wouldn't other people' work only cause issues if they are changing the same files, in which case conflicts would happen even if the work is spread in multiple repos?
Here is the problem: 1- You finished your work, so you pull from the central repository, and merge your your branch to the master 2- You do your merge work, test it a bit and commit 3- Now, you push and oops, another team did the same, you are now left with to heads 4- You merge or rebase the two heads. Probably a simple task, but you may still need to run some tests again. And if you are lucky, you are done, otherwi…
Pros: * Single version / branching for everything * Commits that go across components/apps are atomic. Cons: * When it gets big, those features matter less * Churn from other dev's stuff gets in your merge/rebase work. * 'git log' and other commands can be painfully slow * Mistakes in the repo (e.g., committing a password) now affect many more people. Use for highly-coupled source bases. Where releases together and a…
> Churn from other dev's stuff gets in your merge/rebase work Wouldn't other people' work only cause issues if they are changing the same files, in which case conflicts would happen even if the work is spread in multiple repos?