Working Parents
Yesterday
962
What do you think is wrong with a kid who got rejected by 9 colleges?
Tech Industry
Yesterday
2855
Quitting this Slave life
India
Yesterday
1015
Modi is a legend, will be remembered for centuries to come
Tech Industry
Yesterday
2278
The end of Backdoor Roth?!
Working Parents
14h
1104
Closed now - thank you all
Obviously Google is the big winner here with their 1B+ file repo. MS has a 3M+ file git repo. Any other companies care to comment about their monorepo sizes and what source control systems they are using? Oracle? SAP? IBM?
Windows
Not trolling... I have a lot of respect for your git team.
My bet would be some dinosaur companies with 50 years of legacy stuff.
Doubtful, but that's why I'd love to see whether IBM and others pipe up.
Any thoughts on why google persists with their ridiculous repo? Amazon actively encourages smaller repos - each package is its own repo.
They published a white paper explaining why: Enables atomic code refactor commits, easy code discovery, code sharing, avoids versioning hell, and many other good reasons. The better question for you is why would you want 1000s of individual repos if a monorepo was just as fast?
I’d have to check out the paper first but initial thoughts: 1. Atomic code refactor: Concretely lets say you’re changing the name of ClassA to ClassB. ClassA is widely used across multiple teams. With an individual repo, I’d just refactor using my IDE, increment the version number if it’s a breaking change release. With the monolithic repo, how exactly would this differ? Even if your tools enable refactors across a giant codebase, I don’t think it’s a good idea to make a CR that touches 10 different teams’ codebases, get approvals and ship in one commit. There’s also dead code, how do you figure out who owns what etc etc 2. Code sharing / discovery - Id argue multiple smaller repos is way easier for permission mgmt and code sharing. You get granular r/w permissions out of the box and code search tools work well across multiple repos without a problem. 3. Versioning hell - ?? Need more detail. Clearly maintaining multiple repos is way easier than scaling a humongous repo. And whatever performance hacks you build on top, I find it hard to believe git will as fast on a giant repo as it is on a smaller repo.
How does a team cut a release version in a monorepo scenario since not all teams will share same version time and schedule
I wondered about that too. Also, at ms, a lot of custom work was done to handle the size of the depots from windows teams and others. I cant imagine how much there has to be to do something like a monodepot for a company the size of google.
Benefit of not having 'in production' (not dev/test) enterprise customers who hate touching their stack if it ain't broken and require compatibility until their children go to work!
Google’s advantage is in infrastructure. People do not believe lots of things are possible from outside. Code repo is one example. Worked in MS for many years, was totally surprised to see how it works here.
Monorepo is one of the best perks at Google.
Twitter also operates on a giant Mono repo for all the non client side code
How do you deal with transitive dependencies from open source projects dependencies?
We use a open source build system called pants. It lets us exclude and manage transitive dependencies fairly easily https://www.pantsbuild.org/build_files.html
How is having a mono repo a good idea?
The better question is why some companies think it is better to have 3,000+ repos. Read this for an explanation of mono repos. Why Google Stores Billions of Lines of Code in a Single Repository https://m-cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
Yeah we do this having thousands of repos becomes a major pain in the ass itself
Why obviously?
Because most companies don't invest in the effort needed to make corporate-wide monorepos. Every Oracle team I was on had their own repo. Have things changed? If there is a larger one, I'd love to know.
Ok, gotcha!