Perché le grandi aziende usano Perforce? [chiuso]


113

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

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


34
Ho sentito che Google utilizza cartelle con nome di data e ora su un'unità condivisa! ;)
FrustratedWithFormsDesigner il

10
Solo l'unità condivisa utilizza MapReduce, quindi sono fantastici
Paul Stovell,

4
Un grosso problema sarà il supporto. Quando acquisti Perforce stai acquistando supporto dallo sviluppatore del sistema, qualcosa che potresti non ottenere da Git.
ChrisF

12
@Anto: a chi importa cosa dice Linus? Solo perché sei un geniale sviluppatore del kernel non significa che sai meglio di tutto ovunque.
Billy ONeal,

5
Sono appena arrivato dalla conferenza degli utenti di Perforce 2 settimane fa, posso dirti che Google usa perforce. Ricevono oltre 10.000 invii al giorno al loro 1 server.
aflat

Risposte:


83

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.


3
Grazie per aver fornito una risposta ragionevole oltre alla cinica teoria del "vino e cena". Può essere vero per molte aziende, ma ci sono alcuni motivi legittimi per cui le aziende vanno con Perforce (o lo riscrivono: P). Non riesco a immaginare di provare a gestire l'origine NT in SVN. È vero che SVN e Git stanno recuperando terreno, e forse per un nuovo grande progetto, uno di questi è la decisione giusta. Ma pensa ai costi associati allo spostamento di un progetto live grande quanto Windows (tutte le versioni) da un sistema di controllo del codice sorgente a un altro. Non vale il costo, specialmente quando funziona l'attuale sistema di controllo del codice sorgente.
Greg Jackson,

1
In realtà, sono passati da SLM (uno strumento interno) a Source Depot (un fork di Perforce), quindi probabilmente valeva il costo per qualcuno in quel caso. Ma sì, non vale il costo a meno che non ci sia un vantaggio abbastanza sostanziale.
JasonTrue,

1
discuss.fogcreek.com/joelonsoftware/… ha un po 'di questa storia proveniente principalmente da fonti esterne. (Sono un outsider dal 2004, FWIW).
JasonTrue,

3
Non sono sicuro della grande situazione dei pronti contro termine. Ne gestisco uno, è un repository da 12 GB (ovvero la directory del server compresso è 12 GB) e contiene 320.000 revisioni. È abbastanza veloce. È probabile che Microsoft abbia utilizzato Perforce perché SVN non esisteva nel 1999. maillist.perforce.com/pipermail/perforce-user/2001-August/… e subversion.apache.org/docs/release-notes/release-history.html
gbjbaanb,

8
@gbjbaanb, non è un repository di grandi dimensioni ... oggigiorno è considerato di medie dimensioni. ;) Vedi ad esempio research.google.com/pubs/archive/34459.pdf
Alex Feinman,

65

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.


2
Il problema è che le grandi aziende inseriscono il loro codice in un repository? Che ne dici di mettere ogni 'modulo' o 'applicazione' in un repository Git separato, in modo che le dimensioni di questi repository siano gestibili? Ciascuno di questi repository avrebbe quindi importato le funzionalità richieste utilizzando la funzionalità del sottomodulo di Git. In questo modo, i manutentori dei repository avrebbero occasionalmente i pullloro sottomoduli per ottenere aggiornamenti o nuove funzionalità, e solo allora gli utenti di quel repository avrebbero richiesto aggiornamenti più grandi del codice del repository stesso.
Carl G,

@Carl G: Se leggi tutte le risposte qui, troverai molte ragioni per cui le persone hanno scelto Perforce piuttosto che git che non hanno nulla a che fare con le capacità di git relative ai repository o ai sottomoduli.
Bob Murphy,

Stavo cercando di affrontare "il tempo necessario per popolare inizialmente un albero dei sorgenti", ma in realtà posso vedere che il problema del sottomodulo che ho citato è irrilevante perché i sottomoduli contengono anche tutte le storie di quei repository. Immagino che l'unico modo per ridurre la storia sarebbe usare i binari delle dipendenze.
Carl G

Bene, con git puoi fare un clone superficiale e ottenere solo una piccola quantità di cronologia, o forse solo i file più recenti (git clone --depth 1). Questo funziona anche per i sottomoduli git.
Sahil Singh,

38

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.


4
+1. Siamo passati a git relativamente di recente e abbiamo dovuto eseguire le prestazioni per un tempo piuttosto lungo - solo perché tutto il resto era inferiore.
9000

11
Anche se IMO Perforce perde molto tempo. Lo usiamo ancora al lavoro perché abbiamo investito tempo nello sviluppo di strumenti personalizzati che interagiscono con esso. Per cambiare dovremmo ricostruire quegli strumenti.
m4tt1mus,

2
Perforce e sviluppatori ignoranti mi hanno fatto odiare controllare il codice. Avrei preferito scrivere del codice con il pastello e compilare quello .
Jim Schubert,

Penso che dovresti dare un'occhiata a perforce prima di commentare.
Toby Allen

30

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.

19
Penso che gli sviluppatori "vecchi" (+10 anni) siano probabilmente resistenti ai cambiamenti quanto le persone "non tecniche".
Wayne Werner,

3
+1 su questo, in particolare per questo settore. I programmatori di videogiochi tendono ad avere così tanto sul piatto, che cambiare l'infrastruttura con cui lavorano è una proposta spaventosa. "Se non è rotto ..." è un po 'un mantra e spesso impedisce all'industria di passare da soluzioni più vecchie, anche se potrebbero essere più adatte.
Chris Subagio,

2
@Wayne - commento totalmente antichissimo. Ho più di sessant'anni e sono il principale sostenitore del cambiamento e dell'innovazione nel mio medio-grande sito. James Gosling aveva 46 anni quando iniziò a scrivere la prima JVM. Ken Thomson aveva 49 anni quando inventò lo schema di codifica UTF-8 e 63 quando iniziò a lavorare sulla lingua GO.
James Anderson,

1
@JamesAnderson Penso che probabilmente ci sei lì. E se la tua organizzazione non ha una cultura di miglioramento, vedrai entrare in gioco l' effetto del Mar Morto . Mi chiedo se sia possibile cambiare il sistema nel suo insieme o se possiamo solo giocherellare con la nostra piccola parte di esso.
Wayne Werner,

2
@ MikeO'Connor Hai anche dimenticato di mettere che i giochi usano molte risorse binarie. Essere in grado di bloccare esclusivamente le risorse binarie è un GRANDE vantaggio.
CodingMadeEasy

22

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.


40
Aspetta cosa? Mi hai perso qui "La fusione di Perforce è meglio di Subversion o Git. Git non fa davvero le fusioni [...]". Puoi spiegarlo?
Sverre Rabbelier,

1
In realtà trovo Git abbastanza buono per le fusioni, più piacevole degli strumenti scm della vecchia scuola, ma quando in svn mi manca la possibilità di mettere le cose in un elenco di modifiche "non fare il check-in" come facevo spesso con Perforce. (Ho provato a farlo in SVN, ma alla fine continuo a controllare le cose perché le liste delle modifiche svn e p4 si comportano diversamente).
JasonTrue,

12
@SverreRabbelier 3 anni dopo, e ci sono ancora persone in attesa di una risposta alla tua domanda.
Navin,

1
"perché Perforce è meglio" ... "Questa non è una partita di calcio in cui una squadra è migliore di un'altra". ...
RJFalconer

4
la forza è veloce. molto più veloce di svn o git. --- benchmark, o non è successo ...; p
sjas,

14

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.


Questo è stato un argomento più convincente un decennio fa, ma molti prodotti FOSS sono oggi molto diffusi; tra cui SVN, che viene utilizzato in alcune grandi aziende.
Jeremy,

Non mi interessa che FOSS abbia le cose giuste per competere - mi importa che il mio manager pensi che non lo faccia. Inoltre, alcune grandi aziende si muovono lentamente, quindi ci stanno ancora arrivando, ci vorranno alcuni altri un paio d'anni per valutare la valutazione dei prodotti FOSS.
gbjbaanb,

gbjbaanb Mi hai frainteso. Non credo che i fattori che stai descrivendo siano altrettanto rilevanti a qualsiasi livello di gestione come lo erano dieci anni fa. Mentre quella potrebbe essere la tua situazione, sarebbe errato generalizzarla. FOSS è mainstream, nel senso che è adottato dalla maggior parte delle grandi aziende e utilizzato nei sistemi core.
Jeremy,

6
Penso che questo sia un punto chiave: gli strumenti FOSS non si pubblicizzano, proprio perché non hanno motivo di farlo. Parte di questo sono gli opuscoli e le cose che menzioni, ma anche se Google "sistemi di confronto SCM" o "sistema di controllo della versione di confronto" le uniche cose che trovo sono quelle fatte da Perforce. Certo, devo considerare la fonte, ma non conosco gli strumenti FOSS che si sforzano di pubblicizzare se stessi e parlare del perché sono i migliori. So che guardiamo dall'alto in basso il commercialismo, ma a volte il marketing e la pubblicità mi aiutano davvero a fare una scelta informata.
Probabilità,

1
Penso che ci siano due eccellenti ragioni per non scegliere Perforce: 1. La ramificazione è molto costosa, e 2. Il processo di checkout-poi-modifica rende il lavoro offline molto difficile da conciliare.
Kevin Cline,

14

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.


13
Può sembrare cinico, ma essenzialmente hai colpito l'unghia sulla testa. Nella mia compagnia faccio fatica a promuovere qualsiasi soluzione FOSS, poiché i dirigenti hanno la percezione che se è gratuito non può essere buono.
Wolfgangsz,

1
Per quanto a ciò, anche se avrei potuto convertirli un po 'quando hanno sostituito la nostra soluzione SVN con una' impresa 'che costava una fortuna lanciante, ho richiesto a consulenti, 2 appaltatori di amministrarla e dopo molti lamenti, digrignando i denti, operazione con il passeggino e la morte della nostra produttività ... è stata eliminata e sostituita con la nostra vecchia soluzione SVN.
gbjbaanb,

7
Google non è molto conosciuto per questo tipo di cultura.
Jeremy,

11
@Chance: per quali cose contatta l'assistenza tecnica? Ho usato CVS, Subversion e Mercurial e non mi sono mai trovato a desiderare che ci fosse qualcuno che potessi chiamare. Se ho un problema, google o invio una domanda, ed è risolto, di solito in pochi minuti. Suggerirei che uno strumento di controllo del codice sorgente che richiede il supporto dello sviluppatore del sistema abbia un problema serio.
Tom Anderson,

2
@TobyAllen: non per circa sei anni (nota la data della domanda) Ma in questi giorni sembra che anche Perforce voglia usare qualcosa di diverso da Perforce: perforce.com/git
Dmitri

12

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.


2
Sono d'accordo: questo è un grande motivo per molti dipartimenti IT, ma sembra immaturo. "Non è colpa nostra, è IL LORO GUASTO". Scegliere un prodotto inferiore solo a causa del potenziale di puntamento del dito "da un collo all'altro" sembra una decisione infantile. Non che non sia spesso realizzato, solo che sembra infantile.
Bruce Ediger,

La tua risposta non si riferisce al supporto tecnico di Perforce. Peccato, perché se sapessi quanto fosse bello, la tua risposta potrebbe non essere arrivata. Il supporto tecnico di Perforce è eccezionale e impegnato e risolvono VELOCEMENTE.
Br .ill

9

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


1
Assolutamente, i sottosposi incoraggiano e facilitano il riutilizzo del codice. Questo è il motivo per cui scelgo Perforce quando ho voce in capitolo in merito. Grande affare! Mescola facilmente e abbina il codice da repository diversi (sottorepository di hg), monitorando chi sta utilizzando un sottorepository particolare, capacità di tracciare facilmente check-in, rami e fusioni con tutti i repository. Nel frattempo, lo rende super semplice per lo sviluppatore finale con una specifica client a linea singola e conserva i dettagli nelle specifiche della filiale per i super utenti. In questo momento, sono costretto a utilizzare Mercurial su un grande progetto e gestire i sup-repository con hg costa un sacco di soldi in perdita di produttività.
stephenmm,

8

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.


5
Puoi usare Git bene con diversi flussi di lavoro, quindi essere distribuito non è un problema ... a meno che il team dell'azienda non sia all'oscuro. whygitisbetterthanx.com/#any-workflow
M. Dudley,

2
Non direi che Perforce si ramifica bene ... la creazione di rami Perforce si traduce in una copia occupata di tutto ciò che è ramificato. SVN si ramifica per copia pigra, quindi si ramifica molto più velocemente.
Kevin Cline,

1
@Jason - la ramificazione sulla sovversione avviene più velocemente di quanto io possa digitare: "svn cp ...; svn switch ..." La creazione di rami perforce è follemente complessa; creare una specifica del ramo, creare un'area di lavoro, integrare, eseguire il commit. Cavolo, con forza è tutto così. Senza diramazioni facili e veloci, considero un RCS essenzialmente inutilizzabile. A giudicare dal traffico netto e dalla velocità di miglioramento, sembra che Perforce sia un prodotto a fine vita.
Kevin Cline il

1
@kevin, non sono sicuro di come stai facendo la ramificazione, ma faccio solo la parte di integrazione, commit. Non ho mai fatto le specifiche del ramo e non ho mai dovuto creare uno spazio di lavoro per il ramo (anche se potrei aver dovuto cambiare il mio mapping di vista se avessi deciso di escludere le directory nella mia vista). Detto questo, non ho fatto nulla con svn, quindi non posso commentare quell'aspetto.
Chance

1
@kevin: Sai, se qualcosa "funziona meglio" non è necessariamente una funzione del numero di comandi CLI necessari per farlo. Solo un commento di qualcuno che non è molto competente né in SVN né in Perforce.
Martin Ba,

6

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.


nessun commento, ma voglio sapere quale dei nostri appaltatori o gestori deve giocare a bikini golf!
gbjbaanb,

5
Lo ammetto, Bikini Golf probabilmente lavorerebbe anche su di me.
jhocking

5

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.


2
Si tratta di definire il flusso di lavoro, centralizzato o decentralizzato, non importa. Il lavoro di supporto non è più facile quando si tenta di pettinare 200 filiali nel repository centrale. Nel complesso, le aziende scelgono soluzioni centralizzate perché è ciò con cui si sentono a proprio agio. Non ci sono vantaggi apprezzabili rispetto a un DVCS utilizzato con un repository condiviso centralizzato.
wadesworld,

4

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 !!


4

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.


3

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 .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.