I'm responsible for that BUILD file. Here's why I did it.

Every team at Google stores its code in a single shared monolithic repository with petabytes of code: http://research.google.com/pubs/pub45424.html The Nomulus BUILD files you see in the GitHub repository are actually identical to the ones we use internally.

In order to make the BUILD the same both internally and externally, we needed to have some BUILD files in the open source repository, which at first glance, appear to be superfluous. The reason why @guava//jar is mapped to //java/com/google/common/collect is because that's what it's called in the internal repository. By creating this alias, we don't have to update the hundreds of other deps=[...] lines that reference it.

In the future, our tooling will improve and we will no longer need those files. But for the time being, they're a good workaround.

What stops you from seeing code you aren't allowed (ie. the search algorithm) if its a monolithic repo?

Also, with a repository that large, how do you have it setup locally that is usable?

OP posted a link to a paper that answers your questions: http://research.google.com/pubs/pub45424.html

I believe they used perforce, and switched to an internal tool called Piper, which has ACLs.

I presume that all employees install custom software that work in a way similar to NFS — a distributed file system that avoids having to download everything locally.

Great explanation and interesting insight, thanks!

It's essentially an artifact of the way that third-party dependencies are handled in the Google monorepo. If we had started this project from scratch on GitHub, rather than exporting it at a later date, we most likely would not have gone down this path.