Es gibt viele "Git for Perforce-Benutzer" -Dokumentationen, aber anscheinend nur sehr wenig vom Gegenteil.

Ich habe Git bisher nur verwendet und vor kurzem einen Job begonnen, bei dem ich Perforce häufig verwenden muss, und bin die meiste Zeit sehr verwirrt. Die Konzepte, die ich von Git gewohnt bin, scheinen Perforce überhaupt nicht zuzuordnen zu sein.

Ist jemand daran interessiert, ein paar Tipps für die Verwendung von Perforce für jemanden zusammenzustellen, der an Git gewöhnt ist?

Daran habe ich in den letzten Wochen immer wieder gearbeitet. Es entwickelt sich noch weiter, aber es kann hilfreich sein. Bitte beachten Sie, dass ich ein Perforce-Mitarbeiter bin.

Eine Einführung in Perforce für Git-Benutzer

Zu sagen, dass der Wechsel von Git zu Perforce oder von Perforce zu Git nicht trivial ist, ist eine große Untertreibung. Da es sich um zwei Tools handelt, die angeblich dasselbe tun, könnte ihr Ansatz unterschiedlicher nicht sein. Diese kurze Beschreibung soll neuen Perforce-Benutzern von Git helfen, die neue Welt zu verstehen, in der sie sich befinden.

Ein kurzer Umweg, bevor wir eintauchen; Wenn Sie Git bevorzugen, können Sie Git mit Perforce recht gut verwenden. Wir bieten ein Tool namens Git Fusion, das Git-Repositorys generiert, die mit dem Perforce-Server synchronisiert sind. Git- und Perforce-Mitarbeiter können in Harmonie leben und an demselben Code arbeiten, der von der Wahl der Versionskontrolle durch ihre Mitarbeiter meist nicht beeinflusst wird. Git Fusions 13.3 ist auf der Perforce-Website verfügbar . Es muss zwar vom Perforce-Administrator installiert werden, aber wenn Sie es installieren, werden Sie feststellen, dass die Repository-Slicing-Funktion als Git-Benutzer sehr praktisch sein kann.

Wenn Sie Ihren Administrator nicht davon überzeugen können, Git Fusion zu installieren, wird Git selbst mit einer Perforce-Bindung namens Git-P4 geliefert, mit der Sie mit Git Dateien in einem Perforce-Arbeitsbereich ändern und senden können. Weitere Informationen hierzu finden Sie unter: https://git.wiki.kernel.org/index.php/GitP4

Immer noch hier? Gut, schauen wir uns Perforce an.

Einige terminologische Unterschiede zum Aussortieren

Bevor wir auf die Details eingehen, müssen wir kurz einige terminologische Unterschiede zwischen Git und Perforce behandeln.

Der erste ist die Kasse . In Git erhalten Sie auf diese Weise eine Kopie des Codes von einem bestimmten Zweig in Ihren Arbeitsbereich. In Perforce nennen wir dies eine Synchronisierung über die Befehlszeile oder über unsere GUI P4V "Get Latest Revision". Perforce verwendet das Wort " Checkout" von P4V oder p4 editvon der Befehlszeile aus, um anzuzeigen , dass Sie planen, eine Datei über das Versionskontrollsystem zu ändern. Im Rest dieses Dokuments werde ich die Kaufabwicklung im Sinne von Perforce verwenden.

Das zweite ist Git Commit versus Perforce Submit . Wo Sie sich in Git festlegen würden, werden Sie in Perforce einreichen. Da alle Vorgänge für den gemeinsam genutzten Perforce-Versionsdienst ausgeführt werden, hat Perforce kein Äquivalent für git push. Ebenso haben wir keine pull; Der Synchronisierungsbefehl von oben sorgt dafür, dass Dateien für uns abgerufen werden. In Perforce gibt es kein Konzept für eine reine lokale Übermittlung, es sei denn, Sie verwenden unser unten kurz beschriebenes P4Sandbox-Tool.

Schlüsselkonzepte in Perforce

Wenn ich Perforce auf zwei Schlüsselkonzepte vereinfachen würde, würde ich mich auf das Depot und den Arbeitsbereich konzentrieren. Ein Perforce-Depot ist ein Repository von Dateien, die sich auf einem Perforce-Server befinden. Ein Perforce-Server kann eine beliebige Anzahl von Depots haben und jedes Depot kann eine beliebige Anzahl von Dateien enthalten. Häufig hören Sie, dass Perforce-Benutzer Depot und Server austauschbar verwenden, diese sind jedoch unterschiedlich. Eine Perforce-Site verfügt möglicherweise über mehrere Server. In den meisten Fällen befinden sich jedoch alle Dateien auf einem Server.

Ein Perforce-Arbeitsbereich oder -Client ist ein Objekt im System, das eine Reihe von Dateien auf dem Perforce-Server einem Speicherort im Dateisystem eines Benutzers zuordnet. Jeder Benutzer hat einen Arbeitsbereich für jeden Computer, den er verwendet, und häufig haben Benutzer mehr als einen Arbeitsbereich für denselben Computer. Der wichtigste Teil eines Arbeitsbereichs ist die Zuordnung oder Ansicht des Arbeitsbereichs.

Die Arbeitsbereichsansicht gibt die Dateien im Depot an, die dem lokalen Computer zugeordnet werden sollen. Dies ist wichtig, da die Wahrscheinlichkeit groß ist, dass Sie nicht alle auf dem Server verfügbaren Dateien möchten. In einer Arbeitsbereichsansicht können Sie nur das Set auswählen, das Sie interessiert. Es ist wichtig zu beachten, dass ein Arbeitsbereich Inhalte von mehreren Depots zuordnen kann, jedoch nur Inhalte von einem Server.

Um Perforce in dieser Hinsicht mit Git zu vergleichen, wählen Sie mit Git die Gruppe von Git-Repos aus, an denen Sie interessiert sind. Jedes Repo ist im Allgemeinen eng gefasst und enthält nur verwandte Dateien. Dies hat den Vorteil, dass Sie keine Konfiguration vornehmen müssen. Du machst einen Git-Klon der Dinge, die dir wichtig sind und du bist fertig. Dies ist besonders schön, wenn Sie nur mit einem oder zwei Repositorys arbeiten. Mit Perforce müssen Sie einige Zeit damit verbringen, die gewünschten Codebits auszuwählen.

Viele Perforce-Shops verwenden Streams, die automatisch eine Arbeitsbereichsansicht generieren können, oder sie generieren die Ansicht mithilfe von Skripten oder Vorlagenarbeitsbereichen. Ebenso verlassen viele ihre Benutzer, um ihre Arbeitsbereiche selbst zu generieren. Ein Vorteil der Zuordnung mehrerer Module in einem Arbeitsbereich besteht darin, dass Sie problemlos mehrere Codemodule in einem Check-in ändern können. Sie können sicher sein, dass jeder mit einer ähnlichen Client-Ansicht, der mit Ihrem Check-in synchronisiert wird, den gesamten Code im richtigen Status hat. Dies kann jedoch auch zu übermäßig abhängigem Code führen. Die erzwungene Trennung von Git kann zu einer besseren Modularität führen. Zum Glück kann Perforce auch strikte Modularität unterstützen. Es ist alles eine Frage, wie Sie das Tool verwenden.

Warum Arbeitsbereiche?

Ich denke, wenn man von Git kommt, ist es leicht zu glauben, dass das gesamte Arbeitsbereichskonzept viel mehr Ärger macht, als es wert ist. Im Vergleich zum Klonen einiger Git-Repos ist dies zweifellos richtig. Wo Arbeitsbereiche glänzen und der Grund, warum Perforce nach all den Jahren immer noch im Geschäft ist, ist, dass Arbeitsbereiche eine fantastische Möglichkeit sind, mehrere Millionen Dateiprojekte für Entwickler zu reduzieren und gleichzeitig das Erstellen und Freigeben zu vereinfachen, um die gesamte Quelle zusammenzuführen eine maßgebliche Quelle. Arbeitsbereiche sind einer der Hauptgründe, warum Perforce so gut skalieren kann wie es.

Arbeitsbereiche sind auch insofern hilfreich, als das Layout der Dateien im Depot und das Layout auf dem Computer des Benutzers bei Bedarf variieren können. Viele Unternehmen organisieren ihr Depot so, dass es die Organisation ihres Unternehmens widerspiegelt, sodass die Benutzer Inhalte nach Geschäftsbereichen oder Projekten leicht finden können. Ihr Build-System könnte sich jedoch nicht weniger um diese Hierarchie kümmern. Über den Arbeitsbereich können sie ihre Depothierarchie so neu zuordnen, wie es für ihre Tools sinnvoll ist. Ich habe auch gesehen, dass dies von Unternehmen verwendet wird, die extrem unflexible Build-Systeme verwenden, bei denen Code in sehr spezifischen Konfigurationen vorliegen muss, die für den Menschen äußerst verwirrend sind. Mithilfe von Arbeitsbereichen können diese Unternehmen über eine Quellhierarchie verfügen, die vom Menschen navigiert werden kann, während ihre Build-Tools die Struktur erhalten, die sie benötigen.

Arbeitsbereiche in Perforce werden nicht nur zum Zuordnen der Dateien verwendet, mit denen ein Benutzer arbeiten möchte, sondern sie werden auch vom Server verwendet, um genau zu verfolgen, welche Revisionen jeder Datei der Benutzer synchronisiert hat. Auf diese Weise kann das System beim Synchronisieren den richtigen Satz von Dateien an den Benutzer senden, ohne die Dateien scannen zu müssen, um festzustellen, welche Dateien aktualisiert werden müssen. Bei großen Datenmengen kann dies ein beträchtlicher Leistungsgewinn sein. Dies ist auch in Branchen mit sehr strengen Prüfungsregeln sehr beliebt. Perforce-Administratoren können problemlos verfolgen und protokollieren, welche Entwickler welche Dateien synchronisiert haben.

Weitere Informationen zur vollen Leistung von Perforce-Arbeitsbereichen finden Sie unter Konfigurieren von P4 .

Explizite Kasse vs. implizite Kasse

Eine der größten Herausforderungen für Benutzer, die von Git zu Perforce wechseln, ist das Konzept der expliziten Kaufabwicklung. Wenn Sie an den Git / SVN / CVS-Workflow gewöhnt sind, Dateien zu ändern und dann das Versionskontrollsystem anzuweisen, nach dem zu suchen, was Sie getan haben, kann dies ein äußerst schmerzhafter Übergang sein.

Die gute Nachricht ist, dass Sie bei Bedarf mit einem Workflow im Git-Stil in Perforce arbeiten können. In Perforce können Sie die Option "allwrite" für Ihren Arbeitsbereich festlegen. Dadurch wird Perforce mitgeteilt, dass alle Dateien mit gesetztem beschreibbaren Bit auf die Festplatte geschrieben werden sollen. Sie können dann jede gewünschte Datei ändern, ohne Perforce dies ausdrücklich mitzuteilen. Damit Perforce die von Ihnen vorgenommenen Änderungen abgleichen kann, können Sie "p4 status" ausführen. Es werden Dateien zum Hinzufügen, Bearbeiten und Löschen geöffnet. Wenn Sie auf diese Weise arbeiten, sollten Sie "p4 update" anstelle von "p4 sync" verwenden, um neue Revisionen vom Server zu erhalten. "p4 update" sucht vor der Synchronisierung nach Änderungen, sodass Ihre lokalen Änderungen nicht beeinträchtigt werden, wenn Sie "p4 status" noch nicht ausgeführt haben.

Warum explizite Kasse?

Eine Frage, die ich häufig erhalte, lautet: "Warum sollten Sie jemals eine explizite Kaufabwicklung verwenden?" Auf den ersten Blick scheint es eine verrückte Designentscheidung zu sein, aber das explizite Auschecken hat einige starke Vorteile.

Ein Grund für die Verwendung der expliziten Kaufabwicklung besteht darin, dass keine Dateien mehr nach Inhaltsänderungen durchsucht werden müssen. Während es bei kleineren Projekten ziemlich billig ist, Hashes für jede Datei zu berechnen, um Unterschiede zu finden, haben viele unserer Benutzer Millionen von Dateien in einem Arbeitsbereich und / oder Dateien mit einer Größe von 100 Megabyte, wenn nicht sogar größer. Das Berechnen aller Hashes in diesen Fällen ist äußerst zeitaufwändig. Durch explizites Auschecken weiß Perforce genau, mit welchen Dateien es arbeiten muss. Dieses Verhalten ist einer der Gründe, warum Perforce in großen Dateibranchen wie der Spiele-, Film- und Hardwarebranche so beliebt ist.

Ein weiterer Vorteil ist, dass das explizite Auschecken eine Form der asynchronen Kommunikation bietet, mit der Entwickler allgemein wissen, woran ihre Kollegen arbeiten oder zumindest wo. Es kann Sie wissen lassen, dass Sie möglicherweise vermeiden möchten, in einem bestimmten Bereich zu arbeiten, um unnötige Konflikte zu vermeiden, oder Sie darauf aufmerksam machen, dass ein neuer Entwickler im Team in Code gewandert ist, den er möglicherweise nicht benötigt zu bearbeiten. Meine persönliche Erfahrung ist, dass ich dazu neige, entweder in Git zu arbeiten oder Perforce mit allwrite in Projekten zu verwenden, in denen ich entweder der einzige oder ein seltener Mitwirkender bin, und explizit auszuchecken, wenn ich eng mit einem Team zusammenarbeite. Zum Glück liegt die Wahl bei Ihnen.

Das explizite Auschecken passt auch gut zum Perforce-Konzept ausstehender Änderungslisten. Ausstehende Änderungslisten sind Buckets, in die Sie Ihre geöffneten Dateien einfügen können, um Ihre Arbeit zu organisieren. In Git würden Sie möglicherweise verschiedene Zweige als Buckets für die Organisation der Arbeit verwenden. Zweige sind großartig, aber manchmal ist es schön, Ihre Arbeit in mehrere benannte Änderungen zu organisieren, bevor Sie sie tatsächlich an den Server senden. Mit dem Perforce-Modell, bei dem möglicherweise mehrere Zweige oder mehrere Projekte einem Arbeitsbereich zugeordnet werden, erleichtern ausstehende Änderungslisten die Organisation separater Änderungen.

Wenn Sie eine IDE für die Entwicklung wie Visual Studio oder Eclipse verwenden, empfehle ich dringend, ein Perforce-Plugin für Ihre IDE zu installieren. Die meisten IDE-Plugins checken Dateien automatisch aus, wenn Sie mit der Bearbeitung beginnen, sodass Sie die Prüfung nicht selbst durchführen müssen.

Perforce-Ersetzungen für Git-Funktionen

• git stash ==> p4 shelve
• git local branching ==> entweder Perforce-Regale oder Task-Verzweigungen
• git blame==> p4 annotateoder Perforce Timelapse View über die GUI

Arbeiten getrennt

Es gibt zwei Möglichkeiten, getrennt vom Perforce-Versionsdienst zu arbeiten (das ist unser Begriff für den Perforce-Server).

1) Verwenden Sie P4Sandbox, um eine vollständige lokale Versionierung und lokale Verzweigung zu erhalten

2) Bearbeiten Sie die Dateien nach Ihren Wünschen und verwenden Sie den 'p4-Status', um Perforce mitzuteilen, was Sie getan haben

Mit beiden oben genannten Optionen können Sie die Einstellung "allwrite" in Ihrem Arbeitsbereich verwenden, damit Sie keine Dateien entsperren müssen. Wenn Sie in diesem Modus arbeiten, sollten Sie den Befehl "p4 update" verwenden, um neue Dateien anstelle von "p4 sync" zu synchronisieren. "p4 update" überprüft Dateien auf Änderungen, bevor sie synchronisiert werden.

Perforce-Schnellstart

Alle folgenden Beispiele werden über die Befehlszeile angezeigt.

1) Konfigurieren Sie Ihre Verbindung zu Perforce

export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666

Sie können diese Einstellungen in Ihre Shell-Konfigurationsdatei einfügen, p4 setzum Speichern unter Windows und OS X verwenden oder eine Perforce-Konfigurationsdatei verwenden.

1) Erstellen Sie einen Arbeitsbereich

p4 workspace

# set your root to where your files should live:
Root: /Users/matt/work

# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/...  //demo-workspace/dev/...

2) Holen Sie sich die Dateien vom Server

cd /Users/matt/work
p4 sync

3) Überprüfen Sie die Datei, an der Sie arbeiten möchten, und ändern Sie sie

p4 edit main/foo; 
echo cake >> main/foo

4) Senden Sie es an den Server

p4 submit -d "A trivial edit"

5) Führen Sie diese aus p4 help simple, um die grundlegenden Befehle anzuzeigen, die Sie für die Arbeit mit Perforce benötigen.

Der größte Unterschied zwischen git und p4, auf den sich keine der vorhandenen Antworten bezieht, besteht darin, dass sie unterschiedliche Abstraktionseinheiten verwenden.

• In Git ist die Abstraktion der Patch (auch bekannt als diff, auch bekannt als Changeset). Ein Commit in Git ist im Wesentlichen die Ausgabe der Ausführung diffzwischen dem vorherigen und dem aktuellen Status der festgeschriebenen Dateien.
• Die Abstraktion ist zwangsläufig die Datei . Ein Commit in p4 ist der vollständige Inhalt der Dateien im Commit zu diesem Zeitpunkt. Dies ist in einer Änderungsliste organisiert, aber die Revisionen selbst werden pro Datei gespeichert, und die Änderungsliste sammelt einfach verschiedene Revisionen der Dateien zusammen.

Alles andere ergibt sich aus diesem Unterschied . Das Verzweigen und Zusammenführen in git ist schmerzlos, da aus Sicht der git-Abstraktion jede Datei vollständig rekonstruiert werden kann, indem eine Reihe von Patches der Reihe nach angewendet werden. Um zwei Zweige zusammenzuführen, müssen Sie lediglich alle Patches auf den Quellzweig anwenden Diese sind im Zielzweig nicht in der richtigen Reihenfolge zum Zielzweig vorhanden (vorausgesetzt, es gibt keine Patches auf beiden Zweigen, die sich überlappen).

Perforce-Zweige sind unterschiedlich. Bei einer Verzweigungsoperation in perforce werden Dateien von einem Unterordner in einen anderen kopiert und anschließend die Verknüpfung zwischen den Dateien mit Metadaten auf dem Server markiert. Um eine Datei von einem Zweig zu einem anderen zusammenzuführen ( integrationperforce), betrachtet perforce den vollständigen Inhalt der Datei am Kopf des Quellzweigs und den vollständigen Inhalt der Datei am Kopf des Zielzweigs und ggf. mit einem gemeinsamen Vorfahren zusammenführen. Es ist nicht möglich, Patches einzeln wie Git zu installieren, was bedeutet, dass manuelle Zusammenführungen häufiger auftreten (und schmerzhafter sind).

Es gibt wahrscheinlich nicht viele solcher Dokumentationen, da Perforce ein ziemlich traditionelles Revisionskontrollsystem ist (näher an CVS, Subversion usw.) und normalerweise als weniger kompliziert angesehen wird als moderne verteilte Revisionskontrollsysteme.

Der Versuch, Befehle von einem zum anderen abzubilden, ist nicht der richtige Ansatz. Konzepte von zentralisierten oder verteilten Revisionskontrollsystemen sind nicht dieselben. Stattdessen beschreibe ich einen typischen Workflow in Perforce:

1. Führen Sie p4 editjede Datei aus, die Sie bearbeiten möchten. Sie müssen Perforce mitteilen, welche Dateien Sie bearbeiten. Wenn Sie neue Dateien hinzufügen, verwenden Sie p4 add. Wenn Sie Dateien löschen, verwenden Sie p4 delete.
2. Nehmen Sie Ihre Codeänderungen vor.
3. Ausführen p4 change, um einen Änderungssatz zu erstellen. Hier können Sie eine Beschreibung Ihrer Änderung erstellen und optional auch Dateien zu Ihrem Änderungssatz hinzufügen oder daraus entfernen. Sie können p4 change CHANGE_NUMBERdie Beschreibung bei Bedarf später bearbeiten.
4. Sie können bei Bedarf zusätzliche Codeänderungen vornehmen. Wenn Sie andere Dateien hinzufügen / bearbeiten / löschen müssen, können Sie verwenden p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
5. Führen Sie p4 syncdiese Option aus, um die neuesten Änderungen vom Server abzurufen.
6. Führen Sie p4 resolvediese Option aus, um Konflikte bei der Synchronisierung zu lösen.
7. Wenn Sie bereit sind, Ihre Änderung einzureichen, führen Sie sie aus p4 submit -c CHANGE_NUMBER.

Sie können verwenden p4 revert, um Ihre Änderungen an Dateien zurückzusetzen.

Beachten Sie, dass Sie an mehreren Änderungssätzen gleichzeitig arbeiten können, solange sich keine ihrer Dateien überschneidet. (Eine Datei in Ihrem Perforce-Client kann jeweils nur in einem Änderungssatz geöffnet sein.) Dies kann manchmal nützlich sein, wenn Sie kleine, unabhängige Änderungen vornehmen.

Wenn Sie Dateien bearbeiten müssen, die Sie bereits in einem anderen Änderungssatz geöffnet haben, können Sie entweder einen separaten Perforce-Client erstellen oder Ihren vorhandenen Änderungssatz für später über speichern p4 shelve. (Im Gegensatz dazu git stashwerden die Dateien in Ihrem lokalen Baum beim Zurückstellen nicht zurückgesetzt, daher müssen Sie sie separat zurücksetzen.)