Why Google stores billions of lines of code in a single repository (2016)
12 points by juliethefoxcoon
12 points by juliethefoxcoon
(2016)
Yeah, if you have 100 tiny little repositories, someone(s) in the organization is running around keeping everything synchronized across them. If you aren't the one paying that tax, it probably works great. If you are the one doing the work, or you watch the person(s) frantically doing all the work, then you'll start to realize how high the tax is.
"For historical reasons", mostly.
Like quite a few other folks here, I worked there for many years, and also worked in places that followed different approaches. It has pros and cons, and I think the article oversells some of the benefits. For example, as a security guy, "simplified dependency management" makes me smirk; yes, in theory, you may only have one copy of a particular OSS dependency (although in practice, it'll be more). But if it's used in different ways by 5,000 different services, most of which you've never heard of and that might not have an active owner... any change to that dependency gets really tricky. In particular, remediating security bugs in such ultra-scale dependencies is a fun exercise.
Now, the flip side of that is that in a multi-repo model, usage patterns are more tractable but keeping track of all the repos becomes difficult. So pick your poison, I guess.