Google has an internal build system that builds everything, and it's language independent. Sort of like a distributed make.

Some publicly available information: http://google-engtools.blogspot.ie/2011/08/build-in-cloud-ho... (https://news.ycombinator.com/item?id=2899467)

Yeah, check the comments at http://www.reddit.com/r/golang/comments/2j65lb/go_qa_at_dotg... (specifically the blogspot link and Andrew Gerrand's (enneff's) comment).

They vendor everything.

Yes, we do vendor everything, in that we have a snapshot of all of our dependencies in our source control system. But we do it across the entire codebase, not per project. That is, we typically only ever have a single version of a library for the entire company (with a few exceptions). If a project needs to update to a later version, they basically update everyone using that library. For widely used packages, this can sometimes be a time consuming process, but we've found it to be preferable to the alternative of having version conflicts all over the place. This is generally true not just for Go, but all languages. So the idea of a project needing to pin to a very specific version of a dependency and never update doesn't really fly.

That sounds like a wildly unproductive way to work. Discourages ever changing anything.

It sounds similar to the Linux kernel. If all the providers and consumers of an API are in the same repository, then you can change an API at any time as long as you update all consumers of the API at the same time.

It also results in having a huge version control repo. From what I've heard, Google can't move to git because of this... they're stuck with Perforce because it's the only VCS that can support a repo of their size.

It does discourage upgrading until you really need it. On the other hand, if one person decides to do the work then everyone benefits.

That sounds quite implausible. Sure, one person can go and upgrade the library.

But I find it hard to believe that one person can go and fix up all the projects he's hardly ever heard of that depends on that library.

We have good tools for this. A Googler can create a patch that upgrades a library and run tests for all projects to see what breaks. The project owners review the changes. Of course, some upgrades are easier than others.

In some ways this is similar to what Linux distros do, but sharing common source control, build system, and test runner makes it easier.

I'm going to guess you're a Rubyist. I had to look up what "vendor everything" referred to. There's a reasonably well referenced blog post by a Rubyist -- but only referenced by other Rubyists. I see that the Bundler tool looks for a 'vendor' subdirectory, so I'm going to guess that's how it became a part of the Ruby lexicon.

Anyway, just wanted to point out that it's possible you're using Ruby lingo and not general-purpose tech terms. I could be wrong, maybe I just missed the boat.

I think "bundle everything" might make sense to everybody, including Rubyists.

I remember reading about "vendor" branches in the cvs documentation (probably in the early 2000s), which if I recall correctly were trying to solve a similar problem to sub-modules in git. So I don't think the Rubyists invented the term.

The Subversion book covers the concept of vendor branches extensively:

http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.htm...

That's where I first read the term, but it predates svn. As far as I know, it's been the common term for committing external dependencies to your own VCS for as long as there's been such a thing as a VCS.

We are Nodeists (not nudists - to the best of my knowledge) - we like to use the term "shrinkwrap."

Shrinkwrap isn't quite the same. npm install --save seems to be the closest equivalent, based on discussions I've had with people.

Vendoring means having the physical source code on hand. Not version numbers, not SHAs -- actual checked-out code.

"Vendor everything" was my conclusion to solving dependencies as generally as possible, while trying to knit PostgreSQL modules (locally produced schema chunks) and extensions with a base of versioned Rails apps.