4 ms·
Back when Google was still at Perforce, I used to go to perforce.com to read about how your engineers would never ever wait for Perforce, while waiting for Perf
by Sesse__ 6y ago
Back when Google was still at Perforce, I used to go to perforce.com to read about how your engineers would never ever wait for Perforce, while waiting for Perforce.
The Perforce servers were… large. And backed by large, extremely expensive SANs that worked with RAM as backing store. Yet, it was slow as molasses at Google's scale.
- jeffbee 6y agoPerforce at Google scale in 2010 was "slow" in that it was orders of magnitude faster than git is on much smaller repos today. The only thing that git is really faster for is branching, which is something I almost never wanted to do with Perforce anyway. Git feels fast because it either front-loads all the pain (with checkouts) or defers it (with unexpected runs of git gc) but it doesn't really scale. That's why git users are so vocally opposed to monorepos.
- juped 6y agoAs a committed monorepo opponent, that's not why. "Why" is that it's not possible for a monorepo to have meaningful history. If you don't want to have meaningful history, you're crippling yourself, but you also shouldn't use Git; there are better tools for version control with bad history.
- jeffbee 6y agoAh so I guess it's "not possible" that Google has a meaningful history of their source code and I guess their project, arguably among largest and most profitable of all time, is "crippled". Weird. I wonder how they get anything done over there.
- juped 6y agoGoogle is very unimpressive; the only way I can think of in which they are even tangentially associated with good engineering practices is, well, employing Junio Hamano to, basically, curate the meaningful history of Git.