As someone born in the late 90s, I came of age pretty much thinking that version control was a solved problem, and that the name of the solution was 'git'. But in the course of my work I've noticed there are still lots of niches in industry where git or git-like DVCS doesn't seem to cut it.<p>For instance, some of the larger tech companies use monorepos/megarepos, and for sufficiently large repositories the assumptions that DVCS are built on begin to break down - namely the idea that there's no real server-client distinction and that every client checkout has a complete copy of the repository versioned files and metadata. I know that at both Meta and Google, internal centralized version control systems were developed in order to operate at their scale (SaplingSCM and Piper).<p>But among centralized version control systems, it's Perforce in particular which I'm curious about, because when you talk to people in certain industries (e.g. game studios, graphic design) they pretty much say that Perforce is the only show in town for their use case. I'm wondering how much of this is due to the actual merits of the software versus users just being accustomed to a certain workflow and not wanting to change. I know that for a long time Perforce was one of the few version control systems with a good story for handling unmergeable assets (e.g. binaries, image assets), but is that still true today?<p>I'm wondering because my own experience with the software hasn't been great. The server is kind of a dog to administer, requiring a fair amount of old-school sysadmin work to keep running. I've also found a fair amount of undocumented behavior and bugs (e.g. segfaults) while deploying and administering it. Overall, it just feels like a legacy application.<p>So, HNers - have you used Perforce recently? Does it offer something to you or your team that you just can't get elsewhere? Or is it just an aging product whose remaining users are being squeezed by the private equity firms that currently own it?