6 ms·

I wonder if Google is still using Perforce? That's one of the arguments used at our company to argue that perforce handles huge repos very nicely.

w_t_payne 11y ago
Look at the apache SVN repo. http://svn.apache.org/repos/asf/ http://svn.apache.org/repos/asf/
gecko 11y ago
<wrong>Google is still using don't-look-behind-the-curtain-it's-totally-not-Perforce-but-it's-Perforce</wrong> Google is using a Perforce lookalike that is not actually Perforce, but they're moving to Mercurial. Subversion also scales up to similar sizes, although I confess to not knowing what "similar" means. (I do know that Google did an experiment and concluded that Subversion would scale to their needs, but they were already committed to Perforce by that point.) EDIT: Got corrected by someone who has good reason to know.
- kalmar 11y ago
  > Google is using a Perforce lookalike that is not actually Perforce, but they're moving to Mercurial. Do you have a source for this move to mercurial? This is the second time I've heard it, but couldn't find a source before.
  - gecko 11y ago
    I don't have a publishable source, no, but you can look at the number of @google.com email addresses on the Mercurial mailing list if you want some to do your own inference, or just hang in there for a bit and you won't have to. :)
- rockdoe 11y ago
  I find it curious you were corrected. I think I observed Google employees contributing to improved Mercurial scaling, which also hints in that direction?
  - gecko 11y ago
    I was corrected that Google uses Perforce. They apparently do not anymore, but rather wrote their own Perforce workalike.
    - rockdoe 11y ago
      Oh thanks, I read the correction the wrong way around.
rockdoe 11y ago
There's an older paper/blog from a Google admin describing the set of scripts they use to periodically reboot their Perforce servers. That should tell you how well Perforce handles huge repos, and I imagine it's not gotten better.
- brazzledazzle 11y ago
  I think there's an important distinction between operational/infrastructure/support issues and development workflows and ease of use. While Perforce itself might be a beast to support from an Ops perspective it may provide enough positive benefits to the developers that it's well worth the trade off.
  - rockdoe 11y ago
    I think having to reboot the server periodically (as well as the problems that prompted me to find how Google is running theirs) is evidence enough to argue against "<that> perforce handles huge repos very nicely".
    - brazzledazzle 11y ago
      When people say that perforce handles huge repos well they're referring to a characteristic of the technology not the server implementation of the technology. Git, on its own, is not very user friendly when it comes to large repos or binary files. It's a limitation of the technology regardless of server implementation. Believe me, I'm not saying that perforce is flawless. But there's a reason its used heavily in the game dev and media industries. Does it suck to administer? Certainly. Does that mean that Google's problems with scaling or operating something like perforce apply to most of us? No. Most of us can resolve issues with Perforce by applying some limitations and governance because we're not operating at the massive and distributed scale that google is.
andrewbinstock 11y ago
For years, large codebases at Adobe and Microsoft were built using Perforce. I don't know if they still are today, but the argument that Perforce is good at handling huge codebases is valid.

w_t_payne 11y ago

Look at the apache SVN repo. http://svn.apache.org/repos/asf/ http://svn.apache.org/repos/asf/

gecko 11y ago

<wrong>Google is still using don't-look-behind-the-curtain-it's-totally-not-Perforce-but-it's-Perforce</wrong> Google is using a Perforce lookalike that is not actually Perforce, but they're moving to Mercurial. Subversion also scales up to similar sizes, although I confess to not knowing what "similar" means. (I do know that Google did an experiment and concluded that Subversion would scale to their needs, but they were already committed to Perforce by that point.) EDIT: Got corrected by someone who has good reason to know.

kalmar 11y ago
> Google is using a Perforce lookalike that is not actually Perforce, but they're moving to Mercurial. Do you have a source for this move to mercurial? This is the second time I've heard it, but couldn't find a source before.
- gecko 11y ago
  I don't have a publishable source, no, but you can look at the number of @google.com email addresses on the Mercurial mailing list if you want some to do your own inference, or just hang in there for a bit and you won't have to. :)
rockdoe 11y ago
I find it curious you were corrected. I think I observed Google employees contributing to improved Mercurial scaling, which also hints in that direction?
- gecko 11y ago
  I was corrected that Google uses Perforce. They apparently do not anymore, but rather wrote their own Perforce workalike.
  - rockdoe 11y ago
    Oh thanks, I read the correction the wrong way around.

rockdoe 11y ago

There's an older paper/blog from a Google admin describing the set of scripts they use to periodically reboot their Perforce servers. That should tell you how well Perforce handles huge repos, and I imagine it's not gotten better.

brazzledazzle 11y ago
I think there's an important distinction between operational/infrastructure/support issues and development workflows and ease of use. While Perforce itself might be a beast to support from an Ops perspective it may provide enough positive benefits to the developers that it's well worth the trade off.
- rockdoe 11y ago
  I think having to reboot the server periodically (as well as the problems that prompted me to find how Google is running theirs) is evidence enough to argue against "<that> perforce handles huge repos very nicely".
  - brazzledazzle 11y ago
    When people say that perforce handles huge repos well they're referring to a characteristic of the technology not the server implementation of the technology. Git, on its own, is not very user friendly when it comes to large repos or binary files. It's a limitation of the technology regardless of server implementation. Believe me, I'm not saying that perforce is flawless. But there's a reason its used heavily in the game dev and media industries. Does it suck to administer? Certainly. Does that mean that Google's problems with scaling or operating something like perforce apply to most of us? No. Most of us can resolve issues with Perforce by applying some limitations and governance because we're not operating at the massive and distributed scale that google is.

andrewbinstock 11y ago

For years, large codebases at Adobe and Microsoft were built using Perforce. I don't know if they still are today, but the argument that Perforce is good at handling huge codebases is valid.