Perché le grandi aziende usano Perforce? [chiuso]

Ho sentito parlare di alcune grandi aziende come Google, Facebook utilizzano Perforce

C'è qualche motivo per cui SVN / Git non può sostituire Perforce?

La giustificazione è forse meno pertinente di quanto non fosse una volta, ma Perforce tende a funzionare meglio su grandi repository rispetto a Subversion. Questo è uno dei motivi per cui Microsoft ha acquisito una licenza di origine per Perforce per creare il deposito di origine; Il repository di NT è un mostro e non molti prodotti, commerciali o di altro tipo, potrebbero gestirlo.

Inoltre, almeno in una volta, gli strumenti visivi di Perforce erano molto, molto meglio di quelli disponibili immediatamente (per così dire) con Subversion o Git. Se stai usando Meld, forse quelle cose contano meno di quanto facessero una volta, ma ci sono ancora alcune cose che Perforce ha fatto molto bene, tra cui visualizzazioni di ramificazione e fusione di cui, sebbene non abbia una memoria dettagliata da quando è stato circa 3 anni dall'ultima volta che ho toccato Perforce, mi è sembrato più sofisticato dell'approccio di Github a questo.

Dopo aver utilizzato Perforce, puoi capire quali sono i suoi vantaggi in pratica. Hanno a lungo offerto un'opzione server gratuita per due utenti e, a seconda di quali sistemi di gestione del codice sorgente hai esperienza, potresti trovare il costo dell'aggiornamento dopo che il tuo team lo ha testato per un po '. Per i negozi più piccoli, questo, oltre agli effetti di rete degli sviluppatori che lo hanno utilizzato e apprezzato, sono i motivi per cui Perforce finisce per ottenere utenti paganti. Probabilmente non c'è molto da mangiare e cenare di CTO per vendere Perforce in aziende con piccoli team di sviluppo, in contrasto con le osservazioni ciniche di Dmitri, ma è usato in questi luoghi.

La maggior parte dei progetti a cui ho lavorato al di fuori di Microsoft può essere ragionevolmente ben servita da Git, Mercurial o Subversion, e direi che la maggior parte delle aziende con cui ho lavorato utilizza una di queste opzioni. Ma c'è un punto debole, di solito una combinazione di dimensioni del repository, modello di ramificazione e fusione ed esperienza / storia del team che porta le persone a utilizzare strumenti commerciali. Raramente ho visto grandi repository Git, per esempio. Ciò potrebbe non essere dovuto a limitazioni intrinseche di Git; Lo ammetto per ignoranza totale. Ma in alcuni progetti (come Windows NT) potrebbero esserci dei limiti pratici per le soluzioni gratuite.

Sono abbastanza abile con svn, git e Perforce, sia come utente che nell'impostazione e manutenzione dei server.

Per un'azienda, o anche per un programmatore solitario come me, il controllo del codice sorgente è un costo sostenuto per sostenere l'attività di guadagno reale, che sta sviluppando e vendendo codice. Quindi ci sono diversi fattori da considerare:

• Quanto si adatta al tuo modello di sviluppo?
• Quanto è facile per gli sviluppatori imparare e usare?
• Le operazioni di routine per gli sviluppatori sono veloci?
• Il processo di utilizzo è una distrazione dal loro vero lavoro, ovvero scrivere codice?
• Quanto è facile da configurare e mantenere?
• Quanto costa acquistare e mantenere?
• Se hai bisogno di aiuto, quanto è facile ottenerlo?

Salto i dettagli di t: dr sui pro e contro dei singoli sistemi. Basti dire che quando sono tornato alla consulenza a tempo pieno lo scorso anno, ho esaminato tutti e tre per decidere quale mi avrebbe permesso di guadagnare il più velocemente possibile offrendo software di qualità ai miei clienti e senza richiedere molti soldi non pagati scherzare. Quando ho preso la considerazione politica di "FOSS è buono e non-FOSS è cattivo" dall'equazione, ho finito per chiedere una licenza Perforce.

Ed è per questo che anche le grandi aziende scelgono Perforce.

Ecco i dettagli di tl: dr dai commenti, più un po 'di più.

Affrontare svn è facile: rispetto a Perforce, è un cane lento. Ho lavorato presso un'azienda che ha incorporato Linux per telefoni cellulari e le nostre fonti complete hanno funzionato per 9 GB; hanno usato Perforce. Una volta ottenuto il codice, l'aggiornamento delle ultime fonti normalmente impiegava pochi secondi sulla LAN o un paio di minuti tramite una connessione VPN da casa mia. Con svn, sarebbero stati rispettivamente minuti e ore.

git vs. Perforce è più complicato. Molte aziende ritengono di avere buone ragioni commerciali per utilizzare un repository centralizzato con controllo degli accessi e per rendere più semplice l'impegno lì e difficile fare qualsiasi altra cosa - e Perforce si adatta perfettamente a quel modello. Tuttavia, git incoraggia positivamente le persone a lavorare in una filiale locale e non c'è modo di farlo funzionare diversamente. Uno sviluppatore può lavorare interamente in una filiale locale e non impegnarsi mai nel repository centrale, quindi se un'azienda non vuole che le persone lavorino in quel modo, Perforce è un'opzione migliore.

Ci sono altri problemi con Git per alcune esigenze aziendali. Ho lavorato in un'azienda che utilizzava git e non so quante volte ho sentito questa discussione: "Vorrei che stessimo usando [qualche altro VCS], perché ho bisogno di fare [questo] e non posso farlo con git ". "Certo che puoi farlo con Git." "Come?" "Beh, prima devi scrivere una sceneggiatura bash ..." "Non importa."

E poi c'è il tempo necessario per popolare inizialmente un albero di origine che ha molta storia. Con Perforce, poiché la cronologia è conservata sul server, ottieni solo le ultime versioni di tutti i file, quindi è davvero veloce - anche la configurazione dell'intero albero da 9 GB che ho citato ha impiegato solo un paio d'ore su una VPN. Con Git, può volerci un po 'di tempo tra un tempo lungo e un'eternità. A volte devo clonare GTK + o i repository git X server, e questa è una lunga pausa pranzo, o forse è ora di andare a letto.

Davvero, si tratta dello strumento giusto per il lavoro. svn funziona bene per la maggior parte degli sforzi di Apple open source e sarebbe terribile per l'hacking del kernel. git funziona benissimo per GTK +, ma è incredibilmente lento per lavorare all'interno di WebKit - l'albero dei sorgenti e la storia sono troppo grandi (come ho scoperto nel modo più duro lavorare con il codice dal portale svn-to-git di WebKit). Perforce funziona bene se disponi di un albero di sorgenti giganti e hai bisogno di un controllo centralizzato. Ognuno di loro funziona bene nel giusto contesto.

GIT in particolare, e SVN in una certa misura non sono così vecchi - se avevi bisogno di un controllo della versione solida a metà degli anni '90, dovevi quasi andare in commercio poiché SVN era agli inizi e CVS era, beh, CVS. Una volta investito molto in un sistema, spostarlo può essere un orso.

Oh, e i ragazzi che prendono queste decisioni probabilmente non interagiscono mai con il sistema di controllo della versione, ma vengono vinti e mangiati dal suddetto personale di vendita.

Sono programmatore nel settore dei giochi da quasi 9 anni e ogni progetto su cui ho mai lavorato ha utilizzato Perforce. Sospetto che ci siano alcune cose che mantengono in uso Perforce in quel particolare settore.

• Le persone usano Perforce da molto tempo e si sentono abbastanza a proprio agio con esso, rendendoli titubanti a passare a un'altra soluzione. I decisori possono anche essere riluttanti a mettere il loro progetto da 30 milioni di dollari nelle mani di software che non avevano mai usato prima.
• Molte aziende / team hanno aggiunto il supporto di Perforce ai loro strumenti interni, il che potrebbe richiedere una notevole quantità di lavoro per l'aggiornamento per supportare un altro VCS.
• Mentre i programmatori potrebbero passare facilmente a un altro Git / Hg / SVN, ci sono molti membri meno tecnici di un team di sviluppo del gioco, come artisti, designer e produttori. Metterli a proprio agio con il nuovo sistema potrebbe richiedere molto tempo e sarei disposto a scommettere che sarebbero abbastanza resistenti al cambiamento.

Forse, forse a loro piace Perforce perché Perforce è migliore?

• Perforce è veloce. Molto più veloce di Subversion o Git.
• La fusione di Perforce è migliore di Subversion o Git. Git non si fonde davvero e il tracciamento della versione di Subversion non è così buono, almeno in 1.5.
• Perforce ha un eccellente supporto clienti.
• Perforce combina la revisione del repository di Subversion con le singole revisioni dei file. Perforce consente di visualizzare le revisioni del repository tramite elenchi di modifiche o revisioni di singoli file.
• Perforce fa un lavoro molto migliore con più liste di modifiche rispetto a Subversion. Le liste dei cambiamenti di Subversion sono in qualche modo un ripensamento e conosco pochi che lo usano. Perforce è integrato. Se si sposta un file modificato dall'elenco delle modifiche predefinito, non viene eseguito il commit accidentale.
• Perforce consente di specificare il layout della directory di lavoro. Ad esempio, se si dispone di una struttura di directory del codice sorgente standard, ma alcuni clienti dispongono di una fonte personalizzata, è possibile sovrapporre la fonte personalizzata sulla struttura standard. Puoi effettuare facilmente checkout sparsi specificando solo gli elementi che desideri verificare.

Va bene, prima che tu pensi che io sia un fanboi di Perforce, l'ultima volta che ho consigliato Perforce a un'azienda è stata più di sette anni fa. Perforce costa $ 800 per licenza - che è economico rispetto a ClearCase, ma molto costoso rispetto a Subversion. Ho difficoltà a giustificare Perforce rispetto a Subversion.

Inoltre, la maggior parte degli sviluppatori utilizza Subversion. Non vogliono imparare Perforce che ha un modo diverso di lavorare rispetto a Subversion. In Perforce, devi creare un client e devi contrassegnare i file per la modifica prima di poterli modificare. Non devi farlo con Subversion.

Ci sono anche meno integrazioni con Perforce su Subversion. Parte di ciò è dovuta all'uso del client . Semplicemente non funziona bene con VisualStudio o persino con Hudson. In parte è dovuto al fatto che Perforce deve creare le integrazioni del client.

C'è un costo per la licenza proprietaria chiamare il costo amministrativo. Immagina di poter concedere in licenza un software per $ 1,00 per utente. Diamine, facciamolo due bit. Migliaia di licenze ti costerebbero solo $ 250.

Ora hai bisogno di una persona a tempo pieno che gestisca la licenza. Un lavoratore tecnico medio rimane in un'azienda per circa 2 anni. Ciò significa che 500 persone ogni anno partiranno e altre 500 arriveranno. Dieci persone ogni settimana devono cambiare la licenza. Quindi, ci sono momenti in cui il progetto riprende e sono necessarie altre 250 licenze. Questi devono essere ordinati, inseriti e mantenuti. Questo può richiedere settimane.

Ecco perché molte aziende commerciali sono passate all'open source. Non è il costo di una licenza. Paghi uno sviluppatore $ 150.000 all'anno, che cosa sono altri $ 800 per una licenza Perforce? Gestisce quella licenza. Perforce ha un bell'aspetto rispetto a ClearCase: più veloce, più facile, più economico, migliore. Ma, contro Subversion? Perforce potrebbe essere più veloce e forse migliore, ma è migliore di $ 800? Gestisce meglio la licenza? Non sta usando meglio lo strumento desiderato?

Ecco perché Perforce potrebbe avere problemi.

Git non è lo strumento per tutti. Funziona benissimo in circostanze in cui non si desidera il controllo centralizzato di chi ha accesso a un repository. Ma può essere un dolore in molte circostanze. Il modo in cui lo metto è così:

1. Esegui un progetto open source. Saresti felice o arrabbiato se un milione di persone avesse una copia dell'intero repository?
2. Stai gestendo un trading desk finanziario che utilizza software proprietario per ottenere un vantaggio sui tuoi concorrenti. Saresti felice o arrabbiato se un milione di persone avesse una copia dell'intero repository?

Se stai eseguendo build centralizzate, devi comunque che tutti utilizzino un singolo repository. Qual è il vantaggio di un sistema distribuito in questa circostanza? In effetti, può incoraggiare le persone a lavorare fuori linea . Gli sviluppatori possono semplicemente andare per la loro strada allegra e non impegnarsi fino all'ultimo minuto. Quindi, trascorri due giorni frenetici cercando di far funzionare di nuovo tutto.

Non sono contro Git. Ho raccomandato Git in molti casi. Questi includono team distribuiti con connessioni scarse tra loro o luoghi in cui non si desidera tenere traccia di tutti coloro che hanno accesso al repository di origine.

Ad esempio, un dipartimento di informatica del college voleva che i suoi studenti usassero il controllo del codice sorgente e mettessero lì il loro codice per gli insegnanti. Grande idea. Troppi bambini lasciano il college senza comprendere le procedure standard di sviluppo e costruzione. Ho raccomandato Git.

Usando Git, l'amministratore del repository deve solo prendere impegni dai loro colleghi professori. Non devono preoccuparsi dei singoli studenti. I professori possono consentire agli studenti di impegnarsi nella loro versione del repository. Gli studenti possono lavorare in gruppo e ogni gruppo può condividere la propria versione del repository.

Se il college usasse Subversion, qualcuno dovrebbe conoscere tutti gli studenti e dare loro tutti gli accessi al repository centrale. Dovrebbero gestire chi può controllare cosa e dove. Se un professore assegnasse un progetto di gruppo, questo dovrebbe essere impostato e gestito. Avresti bisogno di una persona a tempo pieno solo per gestirlo.

Questa non è una partita di calcio in cui una squadra è migliore di un'altra. Gli strumenti funzionano in modi diversi e ognuno ha i suoi vantaggi e svantaggi. Perforce è un ottimo strumento. Sfortunatamente, si sono sviluppate circostanze che lo rendono difficile da raccomandare.

Git è fantastico, ma continuo a ricorrere a Subversion per il mio repository di sorgenti personali. Dopotutto, non lo condivido e Subversion è solo più facile da usare. Uso Git per lavoro personale se ho una piccola squadra perché non devo tenere il mio repository a tempo pieno su Internet. Per la maggior parte dei siti commerciali, trovo ancora che Subversion funzioni meglio. Ma ci sono circostanze in cui Git brilla.

Non so se la corruzione 'wine and dine' sia ancora applicabile, ma per la maggior parte dei manager quando decidono di trovare un prodotto leggeranno in varie pubblicazioni (rivolte alla direzione) e guarderanno le brochure e gli opuscoli che esaltano il prodotto virtù.

Indovina, i prodotti FOSS non sono presenti in quei luoghi!

Quindi, è quasi un dato di fatto che la maggior parte delle decisioni di acquisto-gestione sono guidate dalla pubblicità e dal marketing. Possono eseguire valutazioni, ma di alcuni di questi prodotti.

L'altro motivo è dovuto alla maturità. Alcuni prodotti che utilizziamo oggi sono solo recentemente abbastanza stabili per un uso aziendale serio, alcuni non hanno opzioni di supporto, altri non hanno una comprovata esperienza come soluzioni aziendali. Queste sono cose importanti da considerare (anche se come tecnico valuterò felicemente le soluzioni FOSS se il rischio di usarle e farle fallire è minimo per far funzionare l'azienda) e alcuni manager sono giustamente diffidenti di non averle in giro. Sono responsabili nei confronti dei loro capi e si sentiranno molto più a loro agio se c'è un'organizzazione di supporto dietro il prodotto - dopotutto ne hai uno per la tua attività.

Infine, mentre molti prodotti FOSS hanno il supporto dietro di loro (pensate Collabnet o Wandisco per SVN), ottiene ancora la reputazione di "fatto dai geek nella loro camera da letto". Sappiamo tutti che generalmente è b * * ** t e che il migliore FOSS compete incredibilmente bene con le offerte commerciali, ma il mio manager deve ancora essere convinto. forse non capisce la differenza tra i prodotti FOSS immaturi e maturi; forse non gli importa.

Ad ogni modo, Perforce è un ottimo SCM, non c'è motivo di non sceglierlo. Potrei dire lo stesso per altri SCM, ma di nuovo, posso dire solo cose cattive su alcuni altri e avere ancora incubi quando si tratta di un paio di prodotti.

Perché strumenti come Perforce hanno commessi che vendono vino e mangiano persone incaricate dell'acquisto, mentre Git no. Certo, questo è solo il lato cinico di me che parlo, ma è un cinismo provocato dal vedere il processo da vicino.

Giusto per chiarire perfettamente: non intendo dire che ogni volta che vedrai il tuo CIO inciampare ubriaco lungo il corridoio, mi aspetto di usare un nuovo sistema di controllo delle versioni il prossimo trimestre. Solo che esiste una disconnessione in molte organizzazioni tra l'uso e l'acquisizione. Naturalmente ci sono altri motivi per cui le aziende utilizzano Perforce: ad esempio, potrebbero aver già investito molto nella sua implementazione nel loro flusso di lavoro. Ma generalmente --- e questa domanda è molto generale --- non c'è alcun vantaggio funzionale nel non usare gli strumenti FOSS.

Probabilmente lo stesso motivo per cui la mia azienda rifiuta di usare molti software open source (non che io sia d'accordo):

Quando qualcosa va storto, vogliono qualcuno che possano chiamare e urlare.

Mentre tutte le risposte parlano di grandi aziende che utilizzano P4 (e rispondono al motivo per cui Google ha utilizzato P4), uno dei motivi principali per cui Google continua a utilizzare Perforce è che Perforce ti consente di provare un sottostruttura del repository mentre non puoi farlo con Git. Con repository di grandi dimensioni come quello di Google ha fatto una differenza enorme.

E per quanto ho sentito, Facebook usa SVN e Git-SVN

Perché SVN è, beh, SVN e Perforce (da una volta 4 anni fa quando si confrontano gli strumenti) fa alcune cose meglio di SVN . (Penso che il branching sia uno di questi).

E GIT è un Dvcs, come in distribuzione . Per i team aziendali, la parte distribuita potrebbe essere qualcosa che non interessa né desidera.

Un altro motivo per cui le grandi aziende tendono ad acquistare grandi sistemi di controllo della versione "enterprise":

I dirigenti di livello medio-alto nei dipartimenti IT vedono VCS come qualcosa che ogni singolo progetto utilizza, oppure è possibile farne uso. Una volta che hai imposto l'uso di un VCS, allora perché non mettere anche un piccolo "processo"? Voglio dire, hai l'opportunità di specificare un sistema "a livello aziendale", perché non metterlo sotto controllo centrale e aggiungere "disaster recovery" e alcune "funzionalità del flusso di lavoro" in modo da poter dire "Siamo StraightMacket CMM Level conforme!". Un VCS è fin troppo facile da raggiungere per mettere a punto funzioni di applicazione del flusso di lavoro, ecco cosa si riduce.

Per quanto riguarda la scelta di alcuni software maliziosi e rozzi (Serena Dimensions), si dice che alcuni round di Bikini Golf alle Bahamas con alcune donne di 20 agenti di vendita in grado di convincere un direttore o un vicepresidente di qualsiasi cosa.

Le grandi aziende hanno bisogno di un modello centralizzato di qualche tipo. Una volta che gli sviluppatori hanno terminato lo sviluppo, viene distribuito all'assistenza clienti. Vuoi davvero essere nei panni dei supporti quando devono pettinare i repository degli sviluppatori distribuiti 50-200? E le build vengono eseguite in base al repository centrale, le build devono essere sempre, sempre, sempre tracciabili e riproducibili. Lo impari la prima volta che vieni portato in tribunale per qualche stupida violazione di brevetto.

Git non funziona altrettanto bene in questo modello. Se hai un'azienda più piccola o con uno scarso accesso VPN, è lì che brilla davvero.

Uno dei motivi per cui la maggior parte delle grandi aziende usa Perforce potrebbe essere che ci sono più professionisti nel reparto IT che hanno molta conoscenza al riguardo e hanno anni di esperienza nella risoluzione di problemi relativi ad esso.

Sento che in futuro le aziende potrebbero iniziare ad allontanarsi da Perforce e più verso GIT ... la maggior parte degli sviluppatori che conosco sembra preferirla !! Controlla anche http://whygitisbetterthanx.com/#git-is-fast per ulteriori prove sul perché Perforce potrebbe non essere così dominante nei prossimi anni !!

Alcune volte fa, siamo passati da un set di VCS (so per certo che RCS, CVS, ClearCase, Perforce sono stati usati in precedenza, potrebbero essercene anche altri) a Perforce come sistema unico in uso. Non era un piccolo progetto: la migrazione ha richiesto oltre un anno. Il team (non ne facevo parte) incaricato di valutare diversi VCS e almeno sono stati considerati git e svn oltre a quelli già in uso. Come ricordo il loro rapporto, hanno filtrato gli strumenti senza le funzionalità necessarie e quindi hanno considerato:

• prestazioni sull'uso tipico, in particolare per i siti remoti

• requisiti di risorse

• importanza dei cambiamenti necessari nell'abitudine di lavoro

• supporto disponibilità e costi

e Perforce è stato un vincitore abbastanza chiaro nel complesso. git era leggermente migliore per il primo punto, ma in svantaggio per gli altri.

Una volta, non molto tempo fa (quando l'IDE era chiamato VI), gli unici sistemi gratuiti (open source) erano CVS, RCS e SCCS.

• Nessuno di questi potrebbe nemmeno far fronte bene a un file rinominato.
• Non registrarono le fusioni, quindi se si lavoravano attivamente due rami era molto difficile fondersi fino al termine del lavoro su un ramo.
• Non si adattavano bene a basi di codice molto grandi
• Non hanno fornito il livello di controllo degli accessi e informatori di processo desiderati dai grandi progetti.

C'erano molti sistemi di controllo del codice sorgente commerciale là fuori, la maggior parte di questi erano forniti da un unico fornitore di macchine (IBM, DEC, HP, ecc.) E funzionavano solo sul loro hardware.

Quindi alcune società dichiararono di vendere il controllo del codice sorgente commerciale multipiattaforma, tra cui Perforce e ClearCase.

ClearCase è stato costruito su RPC che non funzionava bene su reti geografiche (ma solo Internet) a causa del fatto che molti piccoli pacchetti di rete venivano "sganciati", anche IBM e razionale vedevano ClearCase come una "vacca da mungere" e non lo mostravano mai molto amore.

Quindi l'unico "vecchio" sistema di controllo del codice sorgente commerciale ancora in uso è Perforce. Una volta che perforce è in uso e integrato nei sistemi di build e nei sistemi di tracciamento dei bug, i vantaggi a breve termine di un'azienda per passare a qualsiasi altra cosa.

Quindi, per riassumere, perforce ha ottenuto il "piede nella porta" quando non c'erano molte altre opzioni, e non hanno ancora incasinato abbastanza per convincere le persone ad allontanarsi da esso .