Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Google Stores Billions of Lines of Code in a Single Repository (2016)

cacm.acm.org

Post reply on HN
Print view View original

261–270 of 293 posts

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#261

Post by paulddraper »

marmaduke wrote: post #169
wirrbel wrote: post #153

Earlier quoted context omitted.

Same line of thinking, just different conclusions. I feel terrible for anyone trying to run a company with open-source style independent repos. On a popular github project, you have MANY potential contributors that will tell you if a PR, or a release candidate break API compatibility, etc. There are thousands of hours in open source dedicated to fixing integration issues due to the (unavoidable) poly-repo situation.…

working as dev with academic teams, I usually use many repos for "damage control" as git-ignorant scientists will dump irrelevant files into a repo. with that in mind, is monorepo is a universally good approach or is more dependent on good behavior of team members than polyrepo?

Is there frequent code reuse? If so, monorepos are really nice. If not, separate repos make more sense.

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#262

Post by fps_doug »

jgibson wrote: post #194

Is it just me, or are a lot of people here conflating source control management and dependency management? The two don't have to be combined. For example, if you have Python Project X that depends on Python Project Y, you can either have them A) in different scm repos, with a requirements.txt link to a server that hosts the wheel artifact, B) have them in the same repo and refer to each other from source, or C) have…

It is very tempting to believe that a monorepo will solve all your dependency issues. If you have a project that's say pure python consisting of a client app, a server app, and then a dozen libs, that might actually be true, since you force everyone to always have the latest version of everything, and always be running the latest version. Given a somewhat sane code base and smart IDE, refactoring is really easy and and updates everything atomically.

In reality you often have different components, some written in different languages, at a certain size, not everyone has all the build environment set up and might be working with older binaries, and now it's just as easy to have version mismatches, structural incompatibilities, etc. So you need a strong tooling and integration process to go along with your monorepo. The repo alone doesn't solve all your problems.

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#263

Post by alexeiz »

> Trunk-based development. ... is beneficial in part because it avoids the painful merges that often occur when it is time to reconcile long-lived branches. Development on branches is unusual and not well supported at Google, though branches are typically used for releases.

This sounds like the SVN model to me where branches are cumbersome and therefore they are very rare. After getting used to the Git branching model where branches are free and merges are painless, it would be very hard to go back to the old development model without branches.

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#264

Post by bunderbunder »

adrianN wrote: post #250
justicezyx wrote: post #220

Earlier quoted context omitted.

Single repo is one design that coherently addresses source control management and dependency management. The key is to let the repo be a single comprehensive source of data for building arbitrary artifacts.

A single repo makes it a bit tricky to use some library in version A for project X and version B for project Y.

I think that's actually a good thing. Allowing different projects to use different versions of a 3rd-party package may be convenient for developers in the short term, but it creates bigger problems in the long term.

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#265

Post by adrianN »

bunderbunder wrote: post #264
adrianN wrote: post #250

Earlier quoted context omitted.

A single repo makes it a bit tricky to use some library in version A for project X and version B for project Y.

I think that's actually a good thing. Allowing different projects to use different versions of a 3rd-party package may be convenient for developers in the short term, but it creates bigger problems in the long term.

It depends on the industry. In some places changing a dependency, no matter how trivial the change, entails a lot of work. Think for example about embedded systems where deploying is a lot harder than pushing a Docker image somewhere. It is often far cheaper to analyze whether the fixed bug can be triggered to avoid upgrading unless necessary.

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#266

Post by bunderbunder »

adrianN wrote: post #265
bunderbunder wrote: post #264

Earlier quoted context omitted.

I think that's actually a good thing. Allowing different projects to use different versions of a 3rd-party package may be convenient for developers in the short term, but it creates bigger problems in the long term.

It depends on the industry. In some places changing a dependency, no matter how trivial the change, entails a lot of work. Think for example about embedded systems where deploying is a lot harder than pushing a Docker image somewhere. It is often far cheaper to analyze whether the fixed bug can be triggered to avoid upgrading unless necessary.

In those situations, why not go ahead and keep the code up-to-date and consistent, and simply not deploy when you don't need to?

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#267

Post by gowld »

Khoth wrote: post #202
tiglionabbit wrote: post #108

Earlier quoted context omitted.

XCode also had issues working with large repos. Perhaps they were talking about that?

IIRC their iPhone app had about 20000 classes for some insane reason, and the system didn't handle that well.

https://www.facebook.com/notes/facebook-engineering/under-th...

Facebook patched Android Dalvik to increase the "max methods per app" limit.

Don't know if there's a similar iOs story.

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#268

Post by keerthiko »

hobls wrote: post #28

I feel terrible for anyone who sees this and thinks, “ah! I should move to a monorepo!” I’ve seen it several times, and the thing they all seem to overlook is that Google has THOUSANDS of hours of effort put into the tooling for their monorepo. Slapping lots of projects into a single git repo without investing in tooling will not be a pleasant experience.

What I can advise against is repo partitioning prematurely. I have been on multiple teams that have thought "Oh this will be a common library for all our projects" or "this is a sample project" or "this is the android version and this is the iOS version" and split projects up into different repos, only to wind up with crazy dependencies between repos which have fallen out of sync or require another repo to be on a specific branch/hash to work correctly, causing all kinds of chaos. Split your repos by dependencies, and once your system architecture is kind of fleshed out. Just use branches on the same repo until then.

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#269

Post by mr_tristan »

golangnews wrote: post #199
mr_tristan wrote: post #42

Earlier quoted context omitted.

I sense that Google invests much more in it's infrastructure then most companies make in revenue. I've worked with monorepos, and I'd be loathe to recommend it as well; the combination of culture shift and tooling it takes to keep a monorepo system running makes most CD processes you see today look like child's play. There is a lot of very good free software that supports most of the open source approach to CD these…

What problems specifically did you see? Was this because the repo was too large? I understand at google scale you'd need lots of tooling but why at a smaller scslr of merging a dozen small repos?

The biggest problems are always cultural. Most monorepo workflows really reinforce constant integration, and once you have separate teams with separate managers, I've always witnessed constant conflict that ended up trying to establish spheres of control. It's bizarre - but it's something I've seen at pretty much every place I've worked at.

With all that integration, your single CI toolchain is front and center since everyone's success or failure is tied to it. While projects like bazel exist, how many developers do you know work with bazel every day? I no nobody who does. And most want documented IDE support and ease of use, not some optimal CI workflow. I've found gradle to be OK, but even that kind of pushes everyone toward using Jetbrains tooling. In the end, almost real monorepos have significant custom CI tooling that wires together different toolchains, and, they may have to maintain custom tooling for use in developer machines. And that custom tooling can get expensive to maintain as the project scales up.

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#270

Post by growse »

joe_fishfish wrote: post #244

This is probably a stupid question, but I couldn't find an answer. Does this mean Google keeps all of its different products in all their different languages and environments in one repo? So like, Android lives in the same repo as Gmail, which is the same repo as all the Waymo code and the Google search engine code as well? That seems insane to me.

Why does that seem insane?
Post reply on HN