3 ms·
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:
by jart 10y ago
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 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.
- djhworld 10y agoGreat explanation and interesting insight, thanks!
- bowersbros 10y agoWhat 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?
- hk__2 10y agoOP posted a link to a paper that answers your questions: http://research.google.com/pubs/pub45424.html http://research.google.com/pubs/pub45424.html
- espadrine 10y agoI 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.
- deleted 10y ago[deleted]