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

113

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?

user34401
quelle
34
Ich habe gehört, dass Google Ordner mit Zeitstempelnamen auf einem freigegebenen Laufwerk verwendet! ;)
FrustratedWithFormsDesigner
10
Nur das gemeinsam genutzte Laufwerk verwendet MapReduce, daher sind sie cool
Paul Stovell
4
Ein großes Problem wird die Unterstützung sein. Wenn Sie Perforce kaufen, kaufen Sie Support vom Entwickler des Systems, etwas, das Sie möglicherweise nicht von Git erhalten.
ChrisF
12
@ Anto: Wen interessiert es, was Linus sagt? Nur weil Sie ein brillanter Kernel-Entwickler sind, heißt das noch lange nicht, dass Sie über alles Bescheid wissen.
Billy ONeal
5
Nachdem ich vor zwei Wochen von der Perforce-Benutzerkonferenz gekommen bin, kann ich Ihnen sagen, dass Google Perforce verwendet. Sie erhalten über 10.000 Einreichungen pro Tag an ihren 1 Server.
22.

Antworten:

83

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.

JasonTrue
quelle
3
Vielen Dank für eine vernünftige Antwort neben der zynischen "Wine and Dine" -Theorie. Es mag für viele Unternehmen zutreffen, aber es gibt einige legitime Gründe, warum sich Unternehmen für Perforce entscheiden (oder es umschreiben: P). Ich kann mir nicht vorstellen, mit der NT-Quelle in SVN umzugehen. Es ist wahr, dass SVN und Git aufholen, und für ein neues großes Projekt ist eine davon die richtige Entscheidung. Denken Sie jedoch an die Kosten, die mit dem Umzug eines Live-Projekts von Windows (alle Versionen) von einem Versionsverwaltungssystem auf ein anderes verbunden sind. Es ist die Kosten nicht wert, besonders wenn das aktuelle Versionsverwaltungssystem funktioniert.
Greg Jackson
1
Eigentlich sind sie von SLM (einem internen Tool) zu Source Depot (einer Abzweigung von Perforce) gewechselt, sodass sich die Kosten für jemanden in diesem Fall wahrscheinlich gelohnt haben. Aber ja, es ist die Kosten nicht wert, es sei denn, es gibt einen ziemlich erheblichen Vorteil.
JasonTrue
1
discussion.fogcreek.com/joelonsoftware/… hat einen Teil dieser Geschichte aus größtenteils fremden Quellen. (Ich bin seit 2004 ein Außenseiter, FWIW).
JasonTrue
3
Ich bin mir der großen Repo-Situation nicht sicher. Ich verwalte eine, es ist 12 GB Repo (dh das komprimierte Serververzeichnis ist 12 GB) und hat 320.000 Revisionen. Es ist schnell genug. Möglicherweise hat Microsoft Perforce verwendet, da SVN bereits 1999 nicht existierte. Maillist.perforce.com/pipermail/perforce-user/2001-August/… und subversion.apache.org/docs/release-notes/release-history.html
gbjbaanb
8
@gbjbaanb, das ist kein großes Repository ... heutzutage zählt es als mittelgroßes Repository. ;) Siehe z. B. research.google.com/pubs/archive/34459.pdf
Alex Feinman,
65

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.

Bob Murphy
quelle
2
Ist das Problem, dass große Unternehmen ihren Code in einem Repository ablegen? Wie wäre es, wenn Sie jedes 'Modul' oder 'Anwendung' in ein separates Git-Repository stellen, damit die Größe dieser Repositorys verwaltet werden kann? Jedes dieser Repositorys importiert dann die erforderlichen Funktionen mithilfe der Modulfunktion von Git. Auf diese Weise erhielten die Verwalter der Repositorys gelegentlich pullihre Submodule, um Aktualisierungen oder neue Funktionen zu erhalten, und erst dann erforderten Benutzer dieses Repositorys Aktualisierungen, die größer waren als der Code des Repositorys.
Carl G
@Carl G: Wenn Sie alle Antworten hier lesen, werden Sie feststellen, dass viele Leute Perforce gegenüber Git gewählt haben, die nichts mit den Fähigkeiten von Git in Bezug auf Repositorys oder Submodule zu tun haben.
Bob Murphy
Ich habe versucht, "die Zeit anzugehen, die benötigt wird, um einen Quelltextbaum zu füllen", aber tatsächlich kann ich feststellen, dass das von mir erwähnte Submodulproblem irrelevant ist, da die Submodule auch alle Historien dieser Repositorys enthalten. Ich denke, der einzige Weg, die Geschichte zu reduzieren, wäre die Verwendung von Binärdateien der Abhängigkeiten.
Carl G
Nun, mit git können Sie einen flachen Klon erstellen und nur einen kleinen Teil des Verlaufs oder nur die neuesten Dateien abrufen (git clone - Tiefe 1). Dies funktioniert auch für Git-Submodule.
Sahil Singh
38

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.

Wyatt Barnett
quelle
4
+1. Wir sind vor relativ kurzer Zeit auf Git umgestiegen und mussten ziemlich lange durchhalten - nur weil alles andere minderwertig war.
9000
11
Obwohl IMO Perforce viel Zeit verschwendet. Wir verwenden es immer noch bei der Arbeit, weil wir Zeit in die Entwicklung benutzerdefinierter Tools investiert haben, die damit interagieren. Um zu wechseln, müssten wir diese Tools neu erstellen.
m4tt1mus
2
Perforce und ignorante Entwickler haben mich dazu gebracht, das Einchecken von Code zu hassen. Ich würde lieber Code mit Kreide schreiben und kompilieren , dass .
Jim Schubert
Ich denke, Sie sollten sich vor dem Kommentieren die Perfor- mance ansehen.
Toby Allen
30

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.
Mike O'Connor
quelle
19
Ich denke, "alte" Entwickler (über 10 Jahre) sind wahrscheinlich genauso veränderungsresistent wie "nicht-technische" Leute.
Wayne Werner
3
+1 dazu, speziell für diese Branche. Videospielprogrammierer neigen dazu, so viel auf ihrem Teller zu haben, dass das Ändern der Infrastruktur, mit der sie arbeiten, eine beängstigende Angelegenheit ist. "Wenn es nicht kaputt geht ..." ist ein Mantra und hindert die Branche oft daran, von älteren Lösungen abzuweichen, auch wenn sie möglicherweise besser geeignet sind.
Chris Subagio
2
@ Wayne - total ageist Kommentar. Ich bin über sechzig und der führende Befürworter von Veränderung und Innovation auf meiner mittelgroßen Website. James Gosling war 46, als er anfing, die erste JVM zu schreiben. Ken Thomson war 49 Jahre alt, als er das UTF-8-Codierungsschema entwickelte, und 63 Jahre, als er anfing, an der GO-Sprache zu arbeiten.
James Anderson
1
@ James Anderson Ich denke, Sie sind wahrscheinlich genau richtig. Und wenn Ihre Organisation keine Kultur der Verbesserung aufweist, kommt der Effekt des Toten Meeres zum Tragen. Ich frage mich, ob es möglich ist, das System insgesamt zu ändern, oder ob wir nur an unserem kleinen Teil davon herumspielen können.
Wayne Werner
2
@ MikeO'Connor Du hast auch vergessen, dass Spiele viele binäre Assets verwenden. Binäre Assets exklusiv sperren zu können, ist ein RIESIGES Plus.
CodingMadeEasy
22

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.

David W.
quelle
40
Warte was? Sie haben mich hier verloren. "Perforce-Zusammenführung ist besser als Subversion oder Git. Git führt wirklich keine Zusammenführungen durch [...]". Können Sie das erklären?
Sverre Rabbelier
1
Eigentlich finde ich Git ziemlich gut für Merges, angenehmer als alte scm-Tools, aber wenn ich in svn nicht in der Lage bin, Dinge in eine Änderungsliste "Nicht einchecken" zu packen, wie ich es oft mit Perforce getan habe. (Ich habe versucht, es in SVN zu tun, aber es endet immer noch damit, dass ich Dinge versehentlich einchecke, weil sich svn- und p4-Änderungslisten unterschiedlich verhalten.)
JasonTrue
12
@SverreRabbelier 3 Jahre später warten immer noch Leute auf eine Antwort auf Ihre Frage.
Navin
1
"Weil Perforce besser ist" ... "Dies ist kein Fußballspiel, bei dem eine Mannschaft besser ist als eine andere". ...
RJFalconer
4
Percussion ist schnell. viel schneller als svn oder git. --- Benchmarks, oder es ist nicht passiert ...; p
sjas
14

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.

gbjbaanb
quelle
Dies war vor einem Jahrzehnt ein zwingenderes Argument, aber viele FOSS-Produkte sind heute weit verbreitet. einschließlich SVN, das bei einigen großen Unternehmen eingesetzt wird.
Jeremy
Es ist mir egal, dass FOSS die richtigen Wettbewerbsbedingungen hat - es ist mir wichtig, dass mein Manager denkt, dass dies nicht der Fall ist . Außerdem bewegen sich einige große Unternehmen nur langsam, so dass sie immer noch dort sind. Einige von ihnen werden noch ein paar Jahre brauchen, um über die Bewertung von FOSS-Produkten nachzudenken.
gbjbaanb
gbjbaanb Du verstehst mich falsch. Ich denke nicht, dass die Faktoren, die Sie beschreiben, auf jeder Führungsebene so relevant sind wie vor einem Jahrzehnt. Während das Ihre Situation sein könnte, wäre es falsch, es zu verallgemeinern. FOSS ist Mainstream, das heißt , es wird von den meisten großen Unternehmen und in den Kernsystemen angenommen.
Jeremy
6
Ich denke, das ist ein wichtiger Punkt: FOSS-Tools machen keine Werbung für sich selbst, wirklich, weil sie keinen Grund dazu haben. Ein Teil davon sind die Broschüren und Dinge, die Sie erwähnen, aber selbst wenn ich "Vergleich-SCM-Systeme" oder "Vergleich-Versionskontrollsystem" google, sind die einzigen Dinge, die ich finde, die von Perforce ausgeführt werden. Klar, ich muss die Quelle berücksichtigen, aber ich kenne keine FOSS-Tools, die sich die Mühe machen, für sich zu werben und darüber zu sprechen, warum sie die besten sind. Ich weiß, dass wir auf Kommerzialismus herabblicken, aber manchmal helfen mir Marketing und Werbung, eine fundierte Entscheidung zu treffen.
Chance
1
Ich denke, es gibt zwei gute Gründe, warum Sie sich nicht für Perforce entscheiden sollten: 1. Das Verzweigen ist sehr teuer und 2. Der Prozess des Auscheckens und Bearbeitens macht die Offline-Arbeit sehr schwer miteinander in Einklang zu bringen.
Kevin Cline
14

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.

Dmitri
quelle
13
Es mag zynisch klingen, aber im Grunde haben Sie den Nagel auf den Kopf getroffen. In meiner eigenen Firma kämpfe ich darum, für eine FOSS-Lösung zu werben, da der Geschäftsführer der Ansicht ist, dass es nicht gut sein kann, wenn es kostenlos ist.
Wolfgangsz
1
Amen dazu, obwohl ich sie vielleicht ein wenig konvertiert habe, als sie unsere SVN-Lösung durch eine 'Enterprise'-Lösung ersetzten, die ein flippiges Vermögen kostete, Berater, 2 Auftragnehmer für die Verwaltung und nach vielem Wehklagen, Zähneknirschen und Buggy-Operation und der Tod unserer Produktivität ... wurde verworfen und durch unsere alte SVN-Lösung ersetzt.
gbjbaanb
7
Google ist nicht wirklich für diese Art von Kultur bekannt.
Jeremy
11
@Chance: Für welche Art von Dingen wenden Sie sich an den technischen Support? Ich habe CVS, Subversion und Mercurial verwendet und ich habe mich nie gewünscht, dass es jemanden gibt, den ich anrufen könnte. Wenn ich ein Problem habe, gehe ich auf Google oder poste eine Frage und sie ist in der Regel in wenigen Minuten gelöst. Ich würde vorschlagen , dass ein Source - Control - Tool , das erfordert Unterstützung vom Entwickler des Systems ein ernstes Problem hat.
Tom Anderson
2
@TobyAllen: seit ungefähr sechs Jahren nicht (notiere das Datum der Frage) Aber heutzutage sieht es so aus, als ob sogar Perforce etwas anderes als Perforce verwenden möchte: perforce.com/git
Dmitri
12

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.

Michael
quelle
2
Ich stimme zu: Dies ist ein großer Grund für viele IT-Abteilungen, aber es scheint unausgereift. "Es ist nicht unsere Schuld, es ist IHR FEHLER". Die Auswahl eines minderwertigen Produkts nur aufgrund des Potenzials, mit dem Finger nur einen Hals zu ringen, scheint eine kindliche Entscheidung zu sein. Nicht, dass es nicht oft gemacht wird, nur, dass es kindisch wirkt.
Bruce Ediger
Ihre Antwort bezieht sich nicht auf den technischen Support von Perforce. Schade, denn wenn Sie wüssten, wie gut es war, wäre Ihre Antwort möglicherweise nicht gekommen. Der technische Support von Perforce ist hervorragend und engagiert, und die Probleme werden SCHNELL behoben.
Br.Bill
9

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

manojlds
quelle
1
Absolut, Subrepos fördern und vereinfachen die Wiederverwendung von Code. Deshalb entscheide ich mich für Perforce, wenn ich mitreden kann. Große Sache! Mischen Sie einfach Code aus verschiedenen Repos (hg's Subrepos) und vergleichen Sie ihn. Verfolgen Sie, wer ein bestimmtes Subrepo verwendet. Währenddessen wird es für den Endentwickler mit einer einzeiligen Client-Spezifikation sehr einfach und die Details für die Superuser bleiben in der Branchenspezifikation. Momentan bin ich gezwungen, Mercurial für ein großes Projekt einzusetzen, und der Umgang mit Sup-Repos mit hg kostet eine Menge Geld bei Produktivitätsverlusten.
stephenmm
8

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.

Martin Ba
quelle
5
Sie können Git problemlos mit verschiedenen Workflows verwenden, sodass die Verteilung kein Problem darstellt ... es sei denn, das Firmenteam ist ahnungslos. whygitisbetterthanx.com/#any-workflow
M. Dudley
2
Ich würde nicht sagen, dass Perforce Verzweigungen gut beherrscht. Das Erstellen von Perforce-Verzweigungen führt zu einer ausgelasteten Kopie aller Verzweigungen. SVN verzweigt nach Lazy Copy, so dass es viel schneller verzweigt.
Kevin Cline
1
@Jason - Verzweigung bei Subversion geschieht schneller, als ich eingeben kann: "svn cp ...; svn switch ..." Perforce ist die Erstellung von Verzweigungen wahnsinnig komplex. Erstellen einer Branchenspezifikation, Erstellen eines Arbeitsbereichs, Integrieren, Festschreiben. Verdammt, mit Sicherheit ist das alles so. Ohne schnelle und einfache Verzweigung halte ich ein RCS für im Wesentlichen unbrauchbar. Gemessen am Nettoverkehr und der Geschwindigkeit der Verbesserung scheint Perforce ein Altprodukt zu sein.
Kevin Cline
1
@ Kevin, ich bin mir nicht sicher, wie Sie verzweigen, aber ich mache nur die Integration, Commit-Teil. Ich habe die Branchenspezifikation noch nie erstellt und musste auch nie einen Arbeitsbereich zum Verzweigen erstellen (obwohl ich möglicherweise die Ansichtszuordnung ändern musste, wenn ich mich entschlossen habe, Verzeichnisse in meiner Ansicht auszuschließen). Davon abgesehen habe ich nichts mit svn gemacht, daher kann ich diesen Aspekt nicht kommentieren.
Chance
1
@kevin: Sie wissen, ob etwas "besser funktioniert", hängt nicht unbedingt von der Anzahl der dazu erforderlichen CLI-Befehle ab. Nur ein Kommentar von jemandem, der weder SVN noch Perforce sehr gut beherrscht.
Martin Ba
6

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.

Bruce Ediger
quelle
Kein Kommentar, aber ich möchte wissen, wer von unseren Auftragnehmern oder Managern Bikinigolf spielen darf!
gbjbaanb
5
Ich gebe es zu, Bikini Golf würde wahrscheinlich auch bei mir funktionieren.
jhocking
5

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.

eine Wohnung
quelle
2
Es geht nur darum, Workflows zu definieren, egal ob zentral oder dezentral. Die Arbeit des Supports ist nicht einfacher, wenn Sie versuchen, 200 Filialen im zentralen Repo zu durchsuchen. Im Großen und Ganzen entscheiden sich Unternehmen für zentralisierte Lösungen, weil sie damit vertraut sind. Es gibt keine nennenswerten Vorteile gegenüber einem DVCS, das mit einem zentralisierten gemeinsam genutzten Repository verwendet wird.
Wadesworld
4

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

rrazd
quelle
4

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.

Ein Programmierer
quelle
3

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 .

Ian
quelle