Warum setzen große Unternehmen Perforce ein? [geschlossen]

Ich habe von einigen großen Unternehmen gehört, z. B. von Google und Facebook, die Perforce verwenden

Gibt es einen Grund, warum SVN / Git Perforce nicht ersetzen kann?

Die Rechtfertigung ist vielleicht weniger relevant als früher, aber Perforce schneidet bei großen Repositorys in der Regel besser ab als Subversion. Dies ist einer der Gründe, warum Microsoft eine Quelllizenz für Perforce erworben hat, um Source Depot zu erstellen. Das Repository von NT ist ein Monster, und nicht viele kommerzielle oder sonstige Produkte könnten damit umgehen.

Zumindest einmal waren die visuellen Werkzeuge für Perforce weitaus besser als das, was mit Subversion oder Git (sozusagen) sofort verfügbar war. Wenn Sie Meld verwenden, sind diese Dinge vielleicht weniger wichtig als früher, aber es gibt immer noch ein paar Dinge, die Perforce sehr gut gemacht hat, einschließlich Visualisierungen von Verzweigungen und Zusammenführungen, von denen ich jedoch seitdem keine detaillierten Erinnerungen habe Ungefähr drei Jahre, seit ich Perforce das letzte Mal berührt habe, wirkten sie ausgefeilter als beispielsweise Githubs Ansatz dazu.

Wenn Sie Perforce einmal verwendet haben, werden Sie möglicherweise verstehen, welche Vorteile es in der Praxis hat. Sie bieten seit langem eine kostenlose Serveroption für zwei Benutzer an. Je nachdem, mit welchen Quellcode-Verwaltungssystemen Sie bereits Erfahrung haben, lohnen sich möglicherweise die Upgrade-Kosten, nachdem Ihr Team sie eine Weile getestet hat. Für kleinere Geschäfte sind dies und Netzwerkeffekte von Entwicklern, die es verwendet haben und mögen, der Grund, warum Perforce zahlende Benutzer erhält. Im Gegensatz zu den zynischen Bemerkungen von Dmitri gibt es bei CTOs wahrscheinlich nicht viel zu essen und zu trinken, um Perforce in Unternehmen mit kleinen Entwicklungsteams zu verkaufen, aber es wird an solchen Orten eingesetzt.

Die meisten Projekte, an denen ich außerhalb von Microsoft gearbeitet habe, können von Git, Mercurial oder Subversion recht gut bedient werden, und ich würde sagen, dass die Mehrheit der Unternehmen, für die ich gearbeitet habe, eine dieser Optionen verwendet. Es gibt jedoch einen Sweet Spot, in der Regel eine Kombination aus Repository-Größe, Verzweigungs- und Zusammenführungsmodell und Teamerfahrung / -verlauf, der dazu führt, dass Benutzer kommerzielle Tools verwenden. Ich habe zum Beispiel selten große Git-Repositories gesehen. Dies ist möglicherweise nicht auf intrinsische Einschränkungen von Git zurückzuführen. Ich gebe volle Unwissenheit darüber zu. In einigen Projekten (wie Windows NT) kann es jedoch zu praktischen Einschränkungen bei kostenlosen Lösungen kommen.

Ich beherrsche svn, git und Perforce ziemlich gut, sowohl als Benutzer als auch beim Einrichten und Warten von Servern.

Für ein Unternehmen oder sogar einen einzelnen Programmierer wie mich sind die Kosten für die Quellcodeverwaltung zur Unterstützung der eigentlichen Geldverdienen-Aktivität, bei der Code entwickelt und verkauft wird. Es sind also mehrere Faktoren zu berücksichtigen:

• Wie gut passt es zu Ihrem Entwicklungsmodell?
• Wie einfach ist es für Entwickler zu lernen und zu verwenden?
• Sind Routineoperationen für Entwickler schnell?
• Ist der Prozess der Verwendung eine Ablenkung von ihrem eigentlichen Job, nämlich dem Schreiben von Code?
• Wie einfach ist es einzurichten und zu warten?
• Wie viel kostet der Kauf und die Wartung?
• Wenn Sie Hilfe benötigen, wie einfach ist es, diese zu bekommen?

Ich werde das Detail über die Vor- und Nachteile der einzelnen Systeme überspringen. Es genügt zu sagen, dass ich bei meiner Rückkehr zur Vollzeit-Beratung im letzten Jahr alle drei Punkte überprüft habe, um zu entscheiden, mit welcher Methode ich meinen Kunden das meiste Geld so schnell wie möglich verdienen kann, indem ich qualitativ hochwertige Software bereitstelle, ohne viel unbezahltes Geld zu verlangen herumscherzen. Als ich die politische Überlegung "FOSS ist gut und Nicht-FOSS ist böse" aus der Gleichung herausgenommen habe, habe ich mich für eine Perforce-Lizenz entschieden.

Deshalb entscheiden sich auch große Unternehmen für Perforce.

Hier sind die Details aus den Kommentaren und ein bisschen mehr.

Das Adressieren von svn ist einfach: Im Vergleich zu Perforce ist es hundeschwach. Ich habe bei einem Unternehmen gearbeitet, das Linux für Mobiltelefone eingebettet hat, und unsere vollständigen Quellen haben 9 GB ausgeführt. Sie verwendeten Perforce. Sobald Sie den Code hatten, dauerte die Aktualisierung der neuesten Quellen im LAN normalerweise Sekunden oder ein paar Minuten über eine VPN-Verbindung von meinem Haus. Mit svn wären es Minuten und Stunden gewesen.

Git gegen Perforce ist komplizierter. Viele Unternehmen haben das Gefühl, gute Geschäftsgründe dafür zu haben, ein zentrales Repository mit Zugriffskontrolle zu verwenden und das Festschreiben dort zu vereinfachen und andere Aufgaben zu übernehmen - und Perforce passt perfekt zu diesem Modell. Git ermutigt jedoch positiv dazu, in einer Zweigstelle vor Ort zu arbeiten, und es gibt keine Möglichkeit, es anders zum Laufen zu bringen. Ein Entwickler kann vollständig in einer lokalen Niederlassung arbeiten und sich niemals auf das zentrale Repository festlegen. Wenn ein Unternehmen also nicht möchte, dass seine Mitarbeiter auf diese Weise arbeiten, ist Perforce die bessere Option.

Es gibt andere Probleme mit Git für einige Geschäftsanforderungen. Ich habe in einer Firma gearbeitet, die Git verwendet hat, und ich weiß nicht, wie oft ich diese Diskussion gehört habe: "Ich wünschte, wir hätten [ein anderes VCS] verwendet, weil ich [dies] tun muss und mit Git nicht kann . " "Natürlich kannst du das mit git machen." "Wie?" "Nun, zuerst musst du ein Bash-Skript schreiben ..." "Egal."

Und dann gibt es die Zeit, die benötigt wird, um einen Source-Tree mit viel Geschichte zu füllen. Mit Perforce erhalten Sie, da der Verlauf auf dem Server gespeichert ist, nur die neuesten Versionen aller Dateien. Das ist also sehr schnell - selbst das Einrichten des gesamten 9-GB-Baums, den ich erwähnt habe, über ein VPN dauerte nur ein paar Stunden. Mit git kann es zwischen einer langen Zeit und einer Ewigkeit dauern. Manchmal muss ich GTK + oder die X-Server-Git-Repos klonen, und das ist eine lange Mittagspause oder vielleicht Zeit fürs Bett.

Es ist wirklich eine Frage des richtigen Werkzeugs für den Job. svn funktioniert gut für die meisten Open Source-Bemühungen von Apple und wäre für Kernel-Hacking schrecklich. git funktioniert für GTK + hervorragend, ist aber für die Arbeit in WebKit unglaublich langsam - der Quelltextbaum und der Verlauf sind einfach zu umfangreich (wie ich herausgefunden habe, wie schwierig es ist, mit Code aus dem svn-to-git-Portal von WebKit zu arbeiten). Perforce funktioniert gut, wenn Sie einen riesigen Quelltextbaum haben und eine zentrale Steuerung benötigen. Jeder von ihnen funktioniert gut im richtigen Kontext.

Insbesondere GIT und SVN sind bis zu einem gewissen Grad nicht so alt - wenn Sie Mitte der 90er Jahre eine solide Versionskontrolle brauchten, mussten Sie fast kommerziell werden, da SVN noch in den Kinderschuhen steckte und CVS eben CVS war. Sobald Sie viel in ein System investiert haben, kann es ein Bär sein, es zu bewegen.

Oh, und die Leute, die diese Entscheidungen treffen, interagieren wahrscheinlich nie mit dem Versionskontrollsystem, sondern lassen sich von den oben genannten Vertriebsmitarbeitern verwöhnen.

Ich bin seit fast 9 Jahren Programmierer in der Spieleindustrie, und jedes Projekt, an dem ich jemals gearbeitet habe, hat Perforce verwendet. Ich vermute, dass es in dieser Branche ein paar Dinge gibt, die Perforce im Einsatz halten.

• Die Leute verwenden Perforce schon seit langer Zeit und sind damit ziemlich vertraut, so dass sie zögern, auf eine andere Lösung umzusteigen. Entscheidungsträger zögern möglicherweise auch, ihr 30-Millionen-Dollar-Projekt in die Hände von Software zu legen, die sie noch nie zuvor verwendet haben.
• Viele Unternehmen / Teams haben ihre internen Tools um Perforce-Unterstützung erweitert, was möglicherweise einen erheblichen Arbeitsaufwand für die Aktualisierung zur Unterstützung eines anderen VCS erfordert.
• Während es Programmierern möglicherweise leicht fällt, zu einem anderen Git / Hg / SVN zu wechseln, gibt es eine Menge weniger technischer Mitglieder eines Spieleentwicklungsteams, wie Künstler, Designer und Produzenten. Es könnte eine Menge Zeit in Anspruch nehmen, sie mit dem neuen System vertraut zu machen, und ich würde wetten, dass sie der Änderung ziemlich widerstehen würden.

Vielleicht mögen sie Perforce, weil Perforce besser ist?

• Perforce ist schnell. Viel schneller als Subversion oder Git.
• Perforce-Zusammenführung ist besser als Subversion oder Git. Git führt keine Zusammenführungen durch und das Versions-Tracking von Subversion ist nicht so gut, zumindest in Version 1.5.
• Perforce verfügt über eine hervorragende Kundenbetreuung.
• Perforce kombiniert die Repository-Revision von Subversion mit einzelnen Dateirevisionen. Mit Perforce können Sie Repository-Revisionen über Änderungslisten oder einzelne Dateirevisionen anzeigen .
• Perforce erledigt einen viel besseren Job mit mehreren Änderungslisten als Subversion. Die Änderungslisten von Subversion sind ein wenig nachgedacht, und ich kenne nur wenige, die sie verwenden. Perforce ist integriert. Wenn Sie eine geänderte Datei aus der Standardänderungsliste verschieben, wird sie nicht versehentlich festgeschrieben.
• Mit Perforce können Sie das Layout Ihres Arbeitsverzeichnisses festlegen. Wenn Sie beispielsweise einen Standard-Quellcode-Verzeichnisbaum haben, einige Kunden jedoch einen benutzerdefinierten Quellcode haben, können Sie den Standardbaum mit dem benutzerdefinierten Quellcode überlagern. Sie können problemlos spärliche Auscheckvorgänge ausführen, indem Sie nur die Elemente angeben, die Sie auschecken möchten.

Okay, bevor Sie denken, dass ich ein Perforce-Fanboi bin, war das letzte Mal, dass ich Perforce einem Unternehmen empfohlen habe, mehr als sieben Jahre her. Perforce kostet 800 US-Dollar pro Lizenz - im Vergleich zu ClearCase billig, aber im Vergleich zu Subversion sehr teuer. Es fällt mir schwer, Perforce vor Subversion zu rechtfertigen.

Außerdem sind die meisten Entwickler an Subversion gewöhnt. Sie möchten nicht lernen, wie Perforce anders funktioniert als Subversion. In Perforce müssen Sie einen Client erstellen und Dateien zur Bearbeitung markieren, bevor Sie sie ändern können. Mit Subversion müssen Sie das nicht tun.

Es gibt auch weniger Integrationen mit Perforce über Subversion. Ein Teil davon ist auf die Nutzung des Kunden zurückzuführen . Es funktioniert einfach nicht gut mit VisualStudio oder sogar Hudson. Ein Teil davon ist auf die Tatsache zurückzuführen, dass Perforce die Client-Integrationen erstellen muss.

Für eine proprietäre Lizenz fallen Verwaltungskosten an. Stellen Sie sich vor, Sie könnten eine Software für 1,00 USD pro Benutzer lizenzieren. Verdammt, lass es uns zwei Bits machen. Tausend Lizenzen kosten Sie nur 250 US-Dollar.

Jetzt benötigen Sie eine Vollzeitkraft, die die Lizenz verwaltet. Ein durchschnittlicher Techniker bleibt ca. 2 Jahre in einem Unternehmen. Das bedeutet, dass jedes Jahr 500 Menschen abreisen und weitere 500 kommen werden. Jede Woche müssen zehn Personen die Lizenz ändern lassen. Dann kann es vorkommen, dass das Projekt beendet wird und Sie weitere 250 Lizenzen benötigen. Diese müssen bestellt, eingegeben und gepflegt werden. Das kann Wochen dauern.

Aus diesem Grund sind viele Handelsunternehmen auf Open Source umgestiegen. Es sind nicht die Kosten einer Lizenz. Sie zahlen einem Entwickler 150.000 USD pro Jahr. Was sind weitere 800 USD für eine Perforce-Lizenz? Es verwaltet diese Lizenz. Perforce sieht im Vergleich zu ClearCase großartig aus: Schneller, einfacher, billiger, besser. Aber gegen Subversion? Perforce ist vielleicht schneller und besser, aber sind es 800 US-Dollar besser? Verwaltet es die Lizenz besser? Ist es nicht besser, ein gewünschtes Werkzeug zu verwenden?

Deshalb hat Perforce möglicherweise Probleme.

Git ist nicht das All-In-All-Tool. Dies funktioniert hervorragend, wenn Sie nicht zentral steuern möchten, wer Zugriff auf ein Repository hat. Aber es kann unter vielen Umständen ein Schmerz sein. So habe ich es ausgedrückt:

1. Sie führen ein Open Source-Projekt aus. Wären Sie glücklich oder verärgert, wenn eine Million Menschen eine Kopie Ihres gesamten Archivs hätten?
2. Sie betreiben ein Finanzhandelsbüro, das proprietäre Software verwendet, um Ihren Wettbewerbern einen Vorsprung zu verschaffen. Wären Sie glücklich oder verärgert, wenn eine Million Menschen eine Kopie Ihres gesamten Archivs hätten?

Wenn Sie zentralisierte Builds ausführen, müssen alle Benutzer ohnehin ein einziges Repository verwenden. Was ist der Vorteil eines verteilten Systems unter diesen Umständen? In der Tat kann es Menschen ermutigen , arbeiten Linie ab . Die Entwickler können einfach auf ihre eigene lustige Art losgehen und bis zur letzten Minute nichts mehr begehen. Dann verbringst du zwei hektische Tage damit, alles wieder zum Laufen zu bringen.

Ich bin nicht gegen Git. Ich habe Git in vielen Fällen empfohlen. Dazu gehören verteilte Teams mit schlechten Verbindungen untereinander oder Orte, an denen Sie nicht alle verfolgen möchten, die Zugriff auf das Quellrepository haben.

Zum Beispiel wollte eine Fakultät für Informatik ihre Schüler dazu bringen, die Quellcodeverwaltung zu verwenden und ihren Code dort abzulegen, damit die Lehrer ihn sich ansehen können. Großartige Idee. Zu viele Kinder verlassen das College, ohne die Standard-Build- und -Entwicklungsverfahren zu verstehen. Ich habe Git empfohlen.

Durch die Verwendung von Git muss der Administrator des Repositorys nur die Commits seiner Kollegen entgegennehmen. Sie müssen sich nicht um einzelne Schüler kümmern. Die Professoren können den Studenten erlauben, sich auf ihre Version des Repository festzulegen. Die Schüler können in Gruppen arbeiten und jede Gruppe kann ihre Version des Repositorys freigeben.

Wenn das College Subversion verwenden würde, müsste jemand alle Schüler kennen und ihnen allen Zugriff auf das zentrale Repository gewähren. Sie müssten es schaffen, wer was und wo einchecken kann. Wenn ein Professor ein Gruppenprojekt zuweisen würde, müsste dies eingerichtet und verwaltet werden. Sie brauchen eine Vollzeitkraft, um das zu schaffen.

Dies ist kein Fußballspiel, bei dem eine Mannschaft besser ist als eine andere. Werkzeuge arbeiten auf unterschiedliche Weise und haben ihre Vor- und Nachteile. Perforce ist ein großartiges Werkzeug. Leider haben sich Umstände entwickelt, die es schwierig machen, sie weiterzuempfehlen.

Git ist großartig, aber ich greife immer wieder auf Subversion für mein persönliches Quell-Repository zurück. Schließlich teile ich es nicht und Subversion ist nur einfacher zu bedienen. Ich benutze Git für die persönliche Arbeit, wenn ich ein kleines Team habe, weil ich mein Repository nicht ständig im Internet halten muss. Für die meisten kommerziellen Websites finde ich immer noch, dass Subversion am besten funktioniert. Aber es gibt Umstände, unter denen Git glänzt.

Ich weiß nicht, ob die „Wine and Dine“ -Bestechung noch anwendbar ist, aber für die meisten Manager, die sich entscheiden, ein Produkt zu finden, werden sie in verschiedenen Veröffentlichungen nachlesen (die sich an das Management richten) und sich die Broschüren und Faltblätter ansehen, die die Produkte loben Tugenden.

Ratet mal, FOSS-Produkte sind an diesen Orten nicht erhältlich!

Fast selbstverständlich, dass die meisten Management-Kaufentscheidungen von Werbung und Marketing abhängen. Sie können Bewertungen durchführen, jedoch für mehrere dieser Produkte.

Der andere Grund ist die Fälligkeit. Einige Produkte, die wir heute verwenden, sind erst kürzlich stabil genug für den ernsthaften Geschäftsgebrauch, einige bieten keine Supportoptionen, andere haben keine nachgewiesenen Erfolge als Geschäftslösungen. Dies sind wichtige Dinge, die zu berücksichtigen sind (obwohl ich als Technikfreak gerne FOSS-Lösungen evaluieren werde, wenn das Risiko, sie zu verwenden und nicht zum Laufen zu bringen, minimal ist), und einige Manager zu Recht davor zurückschrecken, sie nicht in der Nähe zu haben. Sie sind ihren Vorgesetzten gegenüber rechenschaftspflichtig und fühlen sich viel wohler, wenn sich hinter dem Produkt eine Support-Organisation befindet - schließlich haben Sie eine für Ihr Unternehmen.

Letztendlich haben viele FOSS-Produkte zwar Unterstützung (denken Sie an Collabnet oder Wandisco für SVN), aber dennoch den Ruf eines "Made by Geeks in ihrem Schlafzimmer hinter dem Haus". Wir alle wissen , dass ist in der Regel b * * ** t und die besten FOSS unglaublich gut mit kommerziellen Angeboten konkurriert, aber mein Manager muss noch überzeugt werden. Vielleicht erkennt er den Unterschied zwischen den unreifen und den ausgereiften FOSS-Produkten einfach nicht. Vielleicht ist es ihm egal.

Wie auch immer, Perforce ist ein gutes SCM, es gibt keinen Grund, es nicht zu wählen. Ich könnte dasselbe für andere SCMs sagen, aber auch hier kann ich nur schlechte Dinge über einige andere sagen und habe immer noch Albträume, wenn es um bestimmte Produkte geht.

Denn Tools wie Perforce haben Verkäufer, die für den Einkauf zuständig sind, während Git dies nicht tut. Natürlich ist das nur die zynische Seite, von der ich spreche, aber es ist ein Zynismus, der dadurch entsteht, dass ich den Prozess aus der Nähe betrachte.

Um es ganz klar zu machen: Ich meine nicht , dass Sie jedes Mal, wenn Sie sehen, dass Ihr CIO betrunken den Korridor entlang stolpert, damit rechnen, im nächsten Quartal ein neues Versionierungssystem zu verwenden. Nur dass es in vielen Organisationen eine Trennung zwischen Nutzung und Erwerb gibt. Natürlich gibt es andere Gründe, warum Unternehmen Perforce einsetzen: Beispielsweise haben sie möglicherweise bereits viel in die Implementierung in ihrem Workflow investiert. Aber im Allgemeinen - und diese Frage ist sehr allgemein - gibt es keinen funktionalen Vorteil, wenn FOSS-Tools nicht verwendet werden.

Wahrscheinlich aus dem gleichen Grund, aus dem mein Unternehmen sich weigert, viel Open-Source-Software zu verwenden (nicht, dass ich damit einverstanden bin):

Wenn etwas schief geht, wollen sie jemanden, den sie anrufen und anschreien können.

Alle Antworten beziehen sich auf große Unternehmen, die P4 verwenden (und sie antworten, warum Google P4 verwendet hat). Einer der Hauptgründe, warum Google Perforce weiterhin verwendet, besteht darin, dass Sie in Perforce einen Teilbaum des Repos auschecken können, während dies mit Git nicht möglich ist. Bei großen Quell-Repos wie dem von Google machte das einen großen Unterschied.

Und soweit ich gehört habe, nutzt Facebook SVN und Git-SVN

Weil SVN eigentlich SVN ist und Perforce (seit 4 Jahren beim Vergleichen von Tools) einige Dinge besser macht als SVN . (Branching ist einer von ihnen, denke ich.)

Und GIT ist ein Dvcs, wie in verteilt . Für Firmenteams ist der verteilte Teil möglicherweise etwas, das weder interessiert noch gewünscht wird.

Ein weiterer Grund, warum große Unternehmen dazu neigen, große, klunkige "Enterprise" -Versionskontrollsysteme zu kaufen:

Das mittlere bis obere Management in den IT-Abteilungen betrachtet VCS als etwas, das von jedem einzelnen Projekt verwendet wird, oder Sie können seine Verwendung erzwingen. Wenn Sie die Verwendung eines VCS erzwungen haben, können Sie dort auch einen kleinen "Prozess" ausführen. Ich meine, Sie haben die Möglichkeit, ein "unternehmensweites" System zu spezifizieren. Warum sollten Sie es nicht zentral steuern und "Disaster Recovery" und einige "Workflow-Funktionen" hinzufügen, damit Sie sagen können: "Wir sind CMM Level StraightJacket." konforme!". Ein VCS ist einfach zu einfach als Ziel, um Workflow-erzwingende Funktionen zu implementieren, worauf es ankommt.

Was die Auswahl an ickky-poo-Software (Serena Dimensions) anbelangt, so kann man mit ein paar Runden Bikini Golf auf den Bahamas mit ein paar 20-köpfigen Vertriebsmitarbeitern einen Direktor oder Vizepräsidenten von so ziemlich allem überzeugen.

Große Unternehmen brauchen eine Art zentrales Modell. Sobald die Entwickler mit der Entwicklung fertig sind, wird sie an den Kundensupport übergeben. Wollen Sie wirklich in Support-Schuhen sein, wenn sie 50-200 verteilte Entwickler-Repos durchkämmen müssen? Und Builds basieren auf dem zentralen Repository, Builds müssen immer, immer, immer nachvollziehbar und reproduzierbar sein. Sie erfahren dies, wenn Sie zum ersten Mal wegen einer dummen Patentverletzung vor Gericht gestellt werden.

Git funktioniert in diesem Modell nicht so gut. Wenn Sie ein kleineres Unternehmen oder ein Unternehmen mit schlechtem VPN-Zugang haben, ist das der Punkt, an dem es wirklich glänzt.

Ein Grund, warum die meisten großen Unternehmen Perforce einsetzen, könnte sein, dass es in der IT-Abteilung mehr Fachleute gibt, die über umfassende Kenntnisse und jahrelange Erfahrung bei der Behebung von Problemen verfügen.

Ich bin der Meinung, dass sich Unternehmen in Zukunft von Perforce und mehr von GIT abwenden werden ... die meisten Entwickler, die ich kenne, scheinen es vorzuziehen !! Lesen Sie auch http://whygitisbetterthanx.com/#git-is-fast, um weitere Hinweise zu erhalten, warum Perforce in den kommenden Jahren möglicherweise nicht so dominant sein wird !!

Vor einiger Zeit haben wir von einer Reihe von VCS (ich weiß sicher, dass RCS, CVS, ClearCase, Perforce früher verwendet wurden, es könnten auch andere sein) zu Perforce als einzigartigem System gewechselt. Das war kein kleines Projekt: Die Migration dauerte über ein Jahr. Das verantwortliche Team (ich war nicht Teil davon) bewertete mehrere VCS, und mindestens Git und Svn wurden als auch die bereits verwendeten berücksichtigt. Soweit ich mich an ihren Bericht erinnere, haben sie die Tools ohne die erforderlichen Funktionen herausgefiltert und dann Folgendes in Betracht gezogen:

• Leistung bei typischer Verwendung, insbesondere für entfernte Standorte

• Ressourcenanforderungen

• Wichtigkeit der notwendigen Änderungen in der Arbeitsweise

• Verfügbarkeit und Kosten des Supports

und Perforce war insgesamt ein klarer Gewinner. Git war etwas besser für den ersten Punkt, aber im Nachteil für die anderen.

Es war einmal, nicht so lange her (wenn die IDE wurde VI genannt), die nur frei (Open Source) Systeme waren CVS, RCS und SCCS.

• Keines dieser Programme kommt mit dem Umbenennen einer Datei zurecht.
• Sie zeichneten keine Zusammenschlüsse auf. Wenn also zwei Zweige aktiv bearbeitet wurden, war es sehr schwierig, die Zusammenschlüsse vorzunehmen, bis die Arbeiten an einem Zweig abgeschlossen waren.
• Sie waren nicht gut auf sehr große Codebasen skalierbar
• Sie boten nicht die von großen Projekten gewünschte Zugriffskontrolle und Prozessinformation.

Es gab viele kommerzielle Quellcodeverwaltungssysteme, die meisten wurden von einem einzigen Maschinenhersteller (IBM, DEC, HP usw.) bereitgestellt und nur auf deren Hardware ausgeführt.

Dann gaben einige Unternehmen an, plattformübergreifende kommerzielle Quellcodeverwaltung zu verkaufen, darunter Perforce und ClearCase.

ClearCase wurde auf RPC aufgebaut, das über WANs (und nur über das Internet) nicht gut funktionierte, da viele kleine Netzwerkpakete "rund" ausgeliefert wurden. Auch IBM und Rational sahen ClearCase als "Cash Cow" an und zeigten nicht viel Liebe.

Daher ist Perforce das einzige "alte" kommerzielle Quellcodeverwaltungssystem, das noch immer in Gebrauch ist. Sobald perforce verwendet und in Build-Systeme und Bug-Tracking-Systeme integriert wurde, hat ein Unternehmen auf kurze Sicht kaum einen Vorteil, wenn es zu etwas anderem übergeht.

Zusammenfassend lässt sich sagen, dass Perce den „Fuß in die Tür“ bekommen hat, als es nicht viele andere Möglichkeiten gab und sie noch nicht genug durcheinander gebracht haben, um die Leute dazu zu bringen, sich davon zu entfernen .