6 ms·
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
by 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 agoI 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 agoI 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 agoWhen 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.