Ho usato perforce "in rabbia", cioè su un progetto; è ottimo per le situazioni in cui l'albero dei sorgenti è estremamente grande: dozzine di centinaia di gigabyte di codice sorgente in più lingue, binari (che non dovrebbero essere stati archiviati), ecc.
Simile a subversion, ti consente di controllare solo una parte di un repository alla volta. Diversamente da subversion, supporta il controllo di più rami di un albero di sorgenti, a diversi livelli, in parallelo. Questo è importante se hai un'app legacy che contemporaneamente ha avuto team diversi che lavorano sulla stessa base di codice e test e seguono diverse convenzioni di directory.
Dopo un periodo iniziale di aggiustamento (meno di una settimana, acceso e spento secondo necessità) ho capito Perforce e i suoi casi d'uso nel mio scenario.
Sono stato nel progetto per meno di quattro mesi; il progetto stesso aveva oltre un decennio.
Non riesco a pensare a un modo ragionevole per il progetto in cui mi trovavo per uscire dalla perforazione; suddividere il repository in sottomoduli porterebbe all'arresto di tutto il lavoro, che in generale è economicamente non fattibile per una grande azienda. Tuttavia, i singoli team possono utilizzare gli strumenti git-to-subversion che aiutano lo sviluppo.
Jenkins (uno strumento di integrazione continua) ha plugin che supportano completamente l'utilizzo di perforce, quindi non è incompatibile con le pratiche agili.
Perforce è decisamente uno strumento "aziendale" in quanto i team più piccoli non ne hanno bisogno a meno che non stiano lavorando con un albero di file mal progettato o con molti file binari di grandi dimensioni (forse gli sviluppatori di videogame oi grafici avrebbero questo bisogno, se stanno condividendo il loro repository di binari controllato dalla versione con uno o più progetti di codice?)