4 ms·

Perforce is still popular.

klodolph 6y ago
I think FB and Google both surpassed Perforce's scale a long time ago. I've heard all these stories about build servers or source control servers where, for the longest time, the solution to scalability problems was to throw larger machines at it. At some point the machines have well into the TBs of RAM, each, and it becomes a major priority to make the system distributed.
- adamnemecek 6y ago
  Perforce scales the best of the bunch.
  - klodolph 6y ago
    It doesn't matter if you're the best if you're not good enough. That's why neither Google nor Facebook use Perforce for most of their code. The repos are just too large.
    - jeffbee 6y ago
      True, but the terminal scale of Perforce at Google was very impressive, and shows that it can handle pretty much anything that 99.9% of companies would need.
      - klodolph 6y ago
        Sure, but Facebook is absolutely in that 0.1%.
    - adamnemecek 6y ago
      What makes you say it's not?
      - klodolph 6y ago
        Personal conversations with people who used to run Perforce at Google.
        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 ago
        Perforce 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 ago
        As 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 ago
        Ah 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.

I think FB and Google both surpassed Perforce's scale a long time ago. I've heard all these stories about build servers or source control servers where, for the longest time, the solution to scalability problems was to throw larger machines at it. At some point the machines have well into the TBs of RAM, each, and it becomes a major priority to make the system distributed.

adamnemecek 6y ago
Perforce scales the best of the bunch.
- klodolph 6y ago
  It doesn't matter if you're the best if you're not good enough. That's why neither Google nor Facebook use Perforce for most of their code. The repos are just too large.
  - jeffbee 6y ago
    True, but the terminal scale of Perforce at Google was very impressive, and shows that it can handle pretty much anything that 99.9% of companies would need.
    - klodolph 6y ago
      Sure, but Facebook is absolutely in that 0.1%.
  - adamnemecek 6y ago
    What makes you say it's not?
    - klodolph 6y ago
      Personal conversations with people who used to run Perforce at Google.
      - 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 ago
        Perforce 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 ago
        As 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 ago
        Ah 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.