Are the source of piper and the build tools also in the mono repo and also developed/deployed off the head branch? Seems like a random engineer could royally fubar things if they broke a service which the build system depends on ...
You said "developed/deployed" as if it were the same thing. Even if you somehow checked in the giant flaw, bypassing all code review and automated testing, it's not like that would suddenly appear in production. Google isn't some PHP hack where you just copy a tarball to The Server. Binaries of even slightly important systems typically go through many stages of deployment, first into unimportant test systems, then us…
Google Is 2B Lines of Code, All in One Place
341–347 of 347 posts
Re: Google Is 2B Lines of Code, All in One Place
#342Direct link to talk (The Motivation for a Monolithic Codebase ): https://www.youtube.com/watch?v=W71BTkUbdqE
Re: Google Is 2B Lines of Code, All in One Place
#343Earlier quoted context omitted.
Wow, $150? Shocked there isn't a cheaper USB version that is more easily hackable. I mean, is it really more than color-changing LEDs in a plastic sphere?
blink(1) is a small USB light to give you glanceable notice of anything on your computer or the internet. blink(1) makes it easy to connect data sources in the cloud or on your computer to a full-color RGB LED so you can know what’s happening https://blink1.thingm.com/
Re: Google Is 2B Lines of Code, All in One Place
#344What are the best practices to follow in a single-repo-multiple-projecrs world? Some people recommend git submodule, others recommend subtree. How do you guys manage alerts and messages - does every developer get a commit notification,or is there a way to filter out messages based upon submodule. How does branching and merging work? I'm wondering what processes are used by non-Google/FB teams to help them be more pro…
FWIW: git submodules are not a single repo by definition. It's just a way to automate the checkout of specifically-versioned external projects without requiring hackery like packing tarballs into the project source. It has its uses, but it's definitely not what they're talking about here.
If you would like to see how things would work with submodules that behaved just like files behave (full distributed workflow) we've got a (unfortunately commercial) solution here:
Re: Google Is 2B Lines of Code, All in One Place
#345Earlier quoted context omitted.
I can't say. I work here, but I don't speak for the company.
Well, you just said what it doesn't have, so I guess you speak for the company after all. Anyway, let me guess. Judging by how the size of all binaries shipped with Windows varied between releases, I'd be inclined to think Windows 10 does not have significantly more lines of code than Windows Vista. So I'd guess at most 100 million lines of code?
Re: Google Is 2B Lines of Code, All in One Place
#346Earlier quoted context omitted.
I can't say. I work here, but I don't speak for the company.
Well, you just said what it doesn't have, so I guess you speak for the company after all. Anyway, let me guess. Judging by how the size of all binaries shipped with Windows varied between releases, I'd be inclined to think Windows 10 does not have significantly more lines of code than Windows Vista. So I'd guess at most 100 million lines of code?
Re: Google Is 2B Lines of Code, All in One Place
#347Earlier quoted context omitted.
Google has tons of services internally that talk via RPC. The monolithic repo means that it's much easier to hunt down and find people that are (say) using an outdated RPC method and help them fix their code. (Just one example of how it's useful even when things are mostly services.)
This discourages you from ever making breaking changes to an API. On the face of it that sounds good but sometimes you do have to make breaking changes. My guess is that there are many duplicate projects in the Google code base for when a breaking change is needed. This is a way to sidestep the problem.
It also encourages writing tools for automating this stuff. A big part of the motivation for polyup (https://github.com/PolymerLabs/polyup) was the fact that we'd be responsible for getting people to upgrade.