it-swarm.dev

Warum verwenden große Unternehmen Perforce?

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

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

119
user34401

Die Begründung ist vielleicht weniger relevant als früher, aber Perforce schneidet bei großen Repositorys tendenziell 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 Tools für Perforce viel, viel besser als das, was mit Subversion oder Git standardmäßig (sozusagen) verfügbar ist. 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 des Verzweigens und Zusammenführens, von denen ich seitdem keine detaillierte Erinnerung mehr habe Ungefähr drei Jahre, seit ich Perforce das letzte Mal berührt habe, schien es raffinierter zu sein als beispielsweise Githubs Herangehensweise daran.

Sobald Sie Perforce 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 Quellcodeverwaltungssystemen Sie Erfahrung haben, lohnt sich das Upgrade möglicherweise, nachdem Ihr Team es eine Weile getestet hat. Für kleinere Geschäfte sind dies und die Netzwerkeffekte von Entwicklern, die es verwendet haben und es gefallen haben, der Grund, warum Perforce zahlende Benutzer erhält. Im Gegensatz zu Dmitris zynischen Äußerungen gibt es im Gegensatz zu Dmitris zynischen Bemerkungen wahrscheinlich nicht viel zu essen und zu essen von CTOs, um Perforce in Unternehmen mit kleinen Entwicklungsteams zu verkaufen, aber es wird an solchen Orten verwendet.

Die meisten Projekte, an denen ich außerhalb von Microsoft gearbeitet habe, können von Git, Mercurial oder Subversion einigermaßen 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, normalerweise eine Kombination aus Repository-Größe, Verzweigungs- und Zusammenführungsmodell und Teamerfahrung/-historie, die 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 zu, dass ich das nicht kenne. In einigen Projekten (wie Windows NT) können kostenlose Lösungen jedoch einige praktische Grenzen haben.

83
JasonTrue

Ich bin mit svn, git und Perforce einigermaßen vertraut, sowohl als Benutzer als auch beim Einrichten und Warten von Servern.

Für ein Unternehmen oder sogar einen einzelnen Programmierer wie mich sind Quellcodeverwaltung Kosten, die zur Unterstützung der echten Geldverdienen-Aktivität anfallen, 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 ihrer eigentlichen Aufgabe, nämlich das Schreiben von Code?
  • Wie einfach ist die Einrichtung und Wartung?
  • 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, als ich letztes Jahr wieder zur Vollzeitberatung zurückkehrte, alle drei überprüft habe, um zu entscheiden, mit welchen ich so schnell wie möglich das meiste Geld verdienen kann, indem ich meinen Kunden hochwertige Software liefere, ohne viel unbezahltes Geld zu benötigen herumscherzen. Als ich die politische Überlegung "FOSS ist gut und Nicht-FOSS ist böse" aus der Gleichung herausnahm, entschied ich mich für eine Perforce-Lizenz.

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


Hier sind die tl: dr Details aus den Kommentaren sowie ein bisschen mehr.

Die Adressierung von svn ist einfach: Im Vergleich zu Perforce ist es hundelang. Ich habe bei einer Firma gearbeitet, die Linux für Mobiltelefone eingebettet hat, und unsere vollständigen Quellen hatten 9 GB; Sie benutzten Perforce. Sobald Sie den Code hatten, dauerte das Aktualisieren der neuesten Quellen normalerweise Sekunden im LAN oder einige Minuten über eine VPN-Verbindung von meinem Haus aus. Mit svn wären es Minuten bzw. Stunden gewesen.

git vs. Perforce ist komplizierter. Viele Unternehmen haben gute geschäftliche Gründe, ein zentrales Repository mit Zugriffskontrolle zu verwenden und es einfach zu machen, sich dort zu engagieren und nichts anderes zu tun - und Perforce passt perfekt zu diesem Modell. Git ermutigt die Leute jedoch positiv, in einer lokalen Niederlassung 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 Repo festlegen. Wenn ein Unternehmen also nicht möchte, dass seine Mitarbeiter auf diese Weise arbeiten, ist Perforce eine 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 würden [ein anderes VCS] verwenden, 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 ..." "Macht nichts."

Und dann gibt es die Zeit, die benötigt wird, um zunächst einen Quellbaum mit viel Geschichte zu füllen. Mit Perforce erhalten Sie, da der Verlauf auf dem Server gespeichert ist, nur die neuesten Versionen aller Dateien, sodass es sehr schnell geht - selbst das Einrichten des gesamten 9-GB-Baums, den ich erwähnt habe, dauerte über ein VPN 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 hervorragend für GTK +, ist aber für die Arbeit in WebKit unglaublich langsam - der Quellbaum und der Verlauf sind einfach zu groß (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 Quellbaum haben und eine zentrale Steuerung benötigen. Jeder von ihnen funktioniert gut im richtigen Kontext.

65
Bob Murphy

Insbesondere GIT und SVN sind bis zu einem gewissen Grad nicht so alt - wenn Sie Mitte der 90er Jahre eine solide Versionskontrolle benötigten, mussten Sie fast kommerziell werden, da SVN noch in den Kinderschuhen steckte und CVS 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 werden von den oben genannten Vertriebsmitarbeitern verwöhnt.

38
Wyatt Barnett

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

  • Die Leute verwenden Perforce schon lange und sind ziemlich vertraut damit, was sie zögern lässt, zu einer anderen Lösung zu wechseln. Entscheidungsträger können auch zögern, 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, für deren Aktualisierung möglicherweise ein erheblicher Arbeitsaufwand erforderlich ist, um ein anderes VCS zu unterstützen.
  • Während es Programmierern leicht fällt, zu einem anderen Git/Hg/SVN zu wechseln, gibt es viele weniger technische Mitglieder eines Spieleentwicklungsteams, wie Künstler, Designer und Produzenten. Es könnte viel Zeit in Anspruch nehmen, sie mit dem neuen System vertraut zu machen, und ich würde wetten, dass sie gegen die Änderung ziemlich resistent sind.
30
Mike O'Connor

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 bietet eine hervorragende Kundenbetreuung.
  • Perforce kombiniert Subversions Repository-Revision mit einzelnen Dateirevisionen. Mit Perforce können Sie Repository-Revisionen über Änderungslisten oder einzelne Dateirevisionen anzeigen.
  • Perforce macht einen viel besseren Job mit mehreren Änderungslisten als Subversion. Die Änderungslisten von Subversion sind eher ein nachträglicher Gedanke, 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 Ihr Arbeitsverzeichnislayout angeben. Wenn Sie beispielsweise einen Standard-Quellcode-Verzeichnisbaum haben, einige Kunden jedoch über eine benutzerdefinierte Quelle verfügen, können Sie die benutzerdefinierte Quelle über den Standardbaum legen. Sie können problemlos spärliche Kassen durchführen, indem Sie nur die Elemente angeben, die Sie kassen möchten.

Okay, bevor Sie glauben, ich sei ein Perforce-Fanboi, habe ich Perforce vor über sieben Jahren das letzte Mal einem Unternehmen empfohlen. Perforce kostet 800 US-Dollar pro Lizenz - was im Vergleich zu ClearCase billig, im Vergleich zu Subversion jedoch sehr teuer ist. Es fällt mir schwer, Perforce gegenüber Subversion zu rechtfertigen.

Außerdem sind die meisten Entwickler an Subversion gewöhnt. Sie wollen nicht Perforce lernen, das anders arbeitet als Subversion. In Perforce müssen Sie ein client erstellen und Dateien zum Bearbeiten 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 Verwendung von client 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 proprietäre Lizenzen fallen Kosten an, die Verwaltungskosten. Stellen Sie sich vor, Sie könnten eine Software für 1,00 USD pro Benutzer lizenzieren. Verdammt, machen wir es zwei Bits. Tausend Lizenzen würden Sie nur 250 US-Dollar kosten.

Jetzt benötigen Sie eine Vollzeitkraft, die die Lizenz verwaltet. Ein durchschnittlicher technischer Mitarbeiter bleibt ungefähr 2 Jahre in einem Unternehmen. Das bedeutet, dass jedes Jahr 500 Menschen abreisen und weitere 500 kommen. Jede Woche müssen zehn Personen die Lizenz ändern. Dann gibt es Zeiten, in denen das Projekt beginnt und Sie weitere 250 Lizenzen benötigen. Diese müssen bestellt, eingegeben und gewartet 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 vielleicht besser, aber sind es 800 Dollar besser? Verwaltet es die Lizenz besser? Ist es nicht besser, ein gewünschtes Werkzeug zu verwenden?

Aus diesem Grund hat Perforce möglicherweise Probleme.

Git ist nicht das A und O. Es funktioniert hervorragend unter Umständen, in denen Sie nicht zentral steuern möchten, wer Zugriff auf ein Repository hat. Aber es kann unter vielen Umständen ein Schmerz sein. Ich habe es so 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 Repositorys hätten?
  2. Sie betreiben einen Financial Trading Desk, der proprietäre Software verwendet, um Ihren Mitbewerbern einen Vorteil zu verschaffen. Wären Sie glücklich oder verärgert, wenn eine Million Menschen eine Kopie Ihres gesamten Repositorys hätten?

Wenn Sie zentralisierte Builds ausführen, muss ohnehin jeder ein einziges Repository verwenden. Was ist unter diesen Umständen der Vorteil eines verteilten Systems? Tatsächlich kann es Menschen dazu ermutigen, zu arbeiten offline. Die Entwickler können einfach ihren eigenen fröhlichen Weg gehen und bis zur letzten Minute nichts begehen. Dann verbringen Sie 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 jeden verfolgen möchten, der Zugriff auf das Quell-Repository hat.

Zum Beispiel wollte eine Informatikabteilung am College 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 üblichen Bau- und Entwicklungsverfahren zu verstehen. Ich habe Git empfohlen.

Durch die Verwendung von Git muss der Administrator des Repositorys nur Commits von seinen Kollegen annehmen. Sie müssen sich nicht um einzelne Schüler kümmern. Die Professoren können den Studenten erlauben, sich auf ihre Version des Repositorys 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 Studenten kennen und ihnen allen Zugriff auf das zentrale Repository gewähren. Sie müssten verwalten, wer was und wo einchecken kann. Wenn ein Professor ein Gruppenprojekt zugewiesen hätte, 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 unterschiedlich und haben ihre Vor- und Nachteile. Perforce ist ein großartiges Werkzeug. Leider haben sich Umstände entwickelt, die es schwierig machen, sie zu empfehlen.

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 einfach einfacher zu bedienen. Ich benutze Git für die persönliche Arbeit, wenn ich ein kleines Team habe, weil ich mein Repository nicht ganz im Internet betreiben 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.

23
David W.

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

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

14
Dmitri

Ich weiß nicht, ob die Bestechung mit Wein und Speisen noch anwendbar ist, aber für die meisten Manager, die sich entscheiden, ein Produkt zu finden, werden sie in verschiedenen Veröffentlichungen (die sich an das Management richten) nachlesen und sich die Broschüren und Faltblätter ansehen, in denen die Produkte gepriesen werden Tugenden.

Ratet mal, FOSS-Produkte gibt es an diesen Orten nicht!

Es ist also fast selbstverständlich, dass die meisten Kaufentscheidungen des Managements von Werbung und Marketing abhängen. Sie können Bewertungen durchführen, jedoch mehrere solcher Produkte.

Der andere Grund liegt in der Fälligkeit. Einige Produkte, die wir heute verwenden, sind erst seit kurzem stabil genug für eine ernsthafte geschäftliche Nutzung, einige haben keine Supportoptionen, andere haben keine nachgewiesene Erfolgsbilanz als Geschäftslösungen. Dies sind wichtige Dinge, die zu beachten sind (obwohl ich als Technikfreak FOSS-Lösungen gerne bewerten werde, wenn das Risiko, sie zu verwenden und zu scheitern, minimal ist, um das Geschäft am Laufen zu halten), und einige Manager sind zu Recht vorsichtig, wenn sie nicht in der Nähe sind. Sie sind ihren Vorgesetzten gegenüber rechenschaftspflichtig und fühlen sich viel wohler, wenn hinter dem Produkt eine Support-Organisation steht - schließlich haben Sie eine für Ihr Unternehmen.

Obwohl viele FOSS-Produkte Unterstützung hinter sich haben (denken Sie an Collabnet oder Wandisco für SVN), hat es dennoch den Ruf, von Geeks in ihrem hinteren Schlafzimmer hergestellt zu werden. Wir alle wissen, dass dies im Allgemeinen b * * ** t ist und das beste FOSS unglaublich gut mit kommerziellen Angeboten konkurriert, aber mein Manager muss noch überzeugt werden. Vielleicht erkennt er den Unterschied zwischen den unreifen und den reifen 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.

14
gbjbaanb

Wahrscheinlich der gleiche Grund, warum 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.

12
Michael

Während alle Antworten über große Unternehmen sprechen, die P4 verwenden (und sie antworten, warum Google P4 verwendet hat), ist einer der Hauptgründe, warum Google Perforce weiterhin verwendet, dass Sie mit Perforce einen Teilbaum des Repos auschecken können, während dies mit Git nicht möglich ist. Bei großen Quell-Repos wie Google machte das einen großen Unterschied.

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

9
manojlds

Weil SVN SVN und Perforce ist (seit 4 Jahren beim Vergleichen von Tools) macht einige Dinge besser als SVN . (Verzweigung ist eine davon, denke ich.)

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

8
Martin Ba

Ein weiterer Grund, warum große Unternehmen dazu neigen, große, klunkige Versionskontrollsysteme für Unternehmen zu kaufen:

Das mittlere bis obere Management in IT-Abteilungen betrachtet VCS als etwas, das jedes einzelne Projekt verwendet, oder Sie können seine Verwendung erzwingen. Wenn Sie die Verwendung eines VCS erzwungen haben, können Sie dann auch einen kleinen "Prozess" einfügen. Ich meine, Sie haben die Möglichkeit, ein "unternehmensweites" System anzugeben, es unter zentrale Kontrolle zu bringen und "Disaster Recovery" und einige "Workflow-Funktionen" hinzuzufügen, damit Sie sagen können: "Wir sind CMM Level StraightJacket konform!". Ein VCS ist einfach zu einfach für ein Ziel, um Funktionen zur Durchsetzung des Workflows bereitzustellen, worauf es ankommt.

Was die Auswahl einer ickky-poo-Software (Serena Dimensions) angeht, so heißt es, dass ein paar Runden Bikini Golf auf den Bahamas mit ein paar weiblichen Vertriebsmitarbeitern einen Direktor oder Vizepräsidenten von fast allem überzeugen können.

6
Bruce Ediger

Große Unternehmen benötigen ein zentrales Modell. Sobald die Entwickler mit der Entwicklung fertig sind, wird es an den Kundensupport übergeben. Möchten Sie wirklich in Unterstützungsschuhen sein, wenn sie 50-200 verteilte Entwickler-Repos durchkämmen müssen? Und Builds basieren auf dem zentralen Repo. 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 dies der Ort, an dem es wirklich glänzt.

5
aflat

Ein Grund, warum die meisten großen Unternehmen Perforce verwenden, kann sein, dass es in der IT-Abteilung mehr Fachleute gibt, die über viel Wissen verfügen und über jahrelange Erfahrung in der Fehlerbehebung verfügen.

Ich bin der Meinung, dass Unternehmen in Zukunft möglicherweise von Perforce weg und mehr in Richtung GIT wechseln werden ... die meisten Entwickler, die ich kenne, scheinen es zu bevorzugen !! Schauen Sie sich auch http://whygitisbetterthanx.com/#git-is-fast an, um weitere Beweise dafür zu erhalten, warum Perforce in den kommenden Jahren möglicherweise nicht so dominant ist !!

4
rrazd

Vor einiger Zeit haben wir von einer Reihe von VCS (ich weiß sicher, dass RCS, CVS, ClearCase, Perforce früher verwendet wurden, es könnte auch andere geben) 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 zumindest git und svn wurden ebenso berücksichtigt wie die bereits verwendeten. Soweit ich mich an ihren Bericht erinnere, haben sie die Tools ohne die erforderlichen Funktionen herausgefiltert und dann Folgendes berücksichtigt:

  • leistung bei typischer Verwendung, insbesondere für Remotestandorte

  • ressourcenanforderungen

  • wichtigkeit der notwendigen Änderungen in der Arbeitsgewohnheit

  • verfügbarkeit und Kosten des Supports

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

4
AProgrammer

Es war einmal vor nicht allzu langer Zeit (als das IDE als VI bezeichnet wurde), waren die einzigen freien (Open Source) Systeme CVS, RCS und SCCS.

  • Keiner von diesen konnte überhaupt mit einer Datei umgehen, die umbenannt wurde.
  • Sie haben keine Zusammenführungen aufgezeichnet. Wenn also zwei Zweige aktiv bearbeitet wurden, war es sehr schwierig, Zusammenführungen durchzuführen, bis die Arbeit an einem Zweig abgeschlossen war.
  • Sie ließen sich nicht gut auf sehr große Codebasen skalieren
  • Sie boten nicht das Maß an Zugangskontrolle und Prozessinformanten, das große Projekte wollten.

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 in Weitverkehrsnetzwerken (und allein im Internet) nicht gut funktionierte, da viele kleine Netzwerkpakete "rund" ausgelöst wurden. Auch IBM und rational sahen ClearCase als "Cash Cow" und zeigten nie viel Liebe.

Daher ist Perforce das einzige „alte“ kommerzielle Quellcodeverwaltungssystem, das noch gebräuchlich ist. Sobald Perforce verwendet und in Build-Systeme und Bug-Tracking-Systeme integriert ist, gibt es für ein Unternehmen nur sehr wenig kurzfristiger Nutzen, um zu etwas anderem überzugehen.

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

3
Ian