Why Google Stores Billions of Lines of Code in a Single Repository (2016)
1–10 of 293 posts
Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)
#2Should probably have a [2016] tag.
Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)
#3Previous thread:
Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)
#4I think monorepos make a lot of sense when you're talking about millions of lines of code. I'm not at all sure they make sense when you're talking about billions.
Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)
#5I think monorepos make a lot of sense when you're talking about millions of lines of code. I'm not at all sure they make sense when you're talking about billions.
I don't think the number of linea matters. I think the interconnection of your code matters. If you have 2 sets of services that are completely uncoupled the having two monorepos for those two deployments make sense. If you can guarantee atomic changes across all services that interconnect you have the benefits monorepos give you.
Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)
#6Managing dependencies and versions across repos is a pain. Refactoring across repos is quite hard when your code spreads across repos considering the tree of dependencies.
Unfortunately Git checkout all the code, including history, at once and it does not scale to big codebases.
The approach that Facebook chose with Mercurial seems a good compromise ( https://code.fb.com/core-data/scaling-mercurial-at-facebook/ )
Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)
#7Previous thread: https://news.ycombinator.com/item?id=11991479
[deleted]
Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)
#8Managing dependencies and versions across repos is a pain. Refactoring across repos is quite hard when your code spreads across repos considering the tree of dependencies. Unfortunately Git checkout all the code, including history, at once and it does not scale to big codebases. The approach that Facebook chose with Mercurial seems a good compromise ( https://code.fb.com/core-data/scaling-mercurial-at-facebook/ )
Git works very well when the code is distributed. Which funnily enough is in the name. That we are using git as a centralized repository is a case of "Why do I need a screwdriver when I have a hammer?".
Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)
#9Managing dependencies and versions across repos is a pain. Refactoring across repos is quite hard when your code spreads across repos considering the tree of dependencies. Unfortunately Git checkout all the code, including history, at once and it does not scale to big codebases. The approach that Facebook chose with Mercurial seems a good compromise ( https://code.fb.com/core-data/scaling-mercurial-at-facebook/ )
Doesn't the Git Virtual File system that Microsoft is contributing to Git take care of this?
https://blogs.msdn.microsoft.com/devops/2017/02/03/announcin...
Edit: don't just down vote. If you have a problem with my comment, tell me why.
Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)
#10I think monorepos make a lot of sense when you're talking about millions of lines of code. I'm not at all sure they make sense when you're talking about billions.
I don't think the number of linea matters. I think the interconnection of your code matters. If you have 2 sets of services that are completely uncoupled the having two monorepos for those two deployments make sense. If you can guarantee atomic changes across all services that interconnect you have the benefits monorepos give you.
Even at google this is true. There are naturally multiple monorepos :) For example the Linux kernel devs have their own. This makes sense since the kernel-user interface is strongly defined.