Frage Perforce für Git Benutzer? [geschlossen]


Es gibt eine Menge von "Git für Perforce Benutzer" -Dokumentation da draußen, aber scheinbar sehr wenig vom Gegenteil.

Ich habe Git vorher nur benutzt und vor kurzem eine Arbeit angefangen, bei der ich Perforce sehr oft verwenden muss und ich bin oft sehr verwirrt. Die Konzepte, die ich von Git gewohnt bin, scheinen Perforce überhaupt nicht zuzuordnen.

Möchte jemand ein paar Tipps für die Verwendung von Perforce für jemanden erstellen, der an Git gewöhnt ist?


143
2018-06-24 02:24


Ursprung


Antworten:


Das ist etwas, woran ich in den letzten paar Wochen immer wieder gearbeitet habe. Es entwickelt sich immer noch, aber es könnte hilfreich sein. Bitte beachten Sie, dass ich ein Perforce-Mitarbeiter bin.

Ein Einstieg in Perforce für Git-Benutzer

Zu sagen, dass der Übergang von Git zu Perforce oder von Perforce zu Git nicht trivial ist, ist eine große Untertreibung. Als zwei Werkzeuge, die scheinbar das Gleiche tun, könnte ihr Ansatz nicht unterschiedlicher sein. Diese kurze Zusammenfassung wird versuchen, neuen Perforce-Benutzern, die von Git kommen, zu helfen, die neue Welt, in der sie sich befinden, zu verstehen.

Ein kurzer Umweg bevor wir eintauchen; Wenn Sie Git bevorzugen, können Sie Git mit Perforce ziemlich gut verwenden. Wir stellen ein Tool namens Git Fusion zur Verfügung, das Git-Repositories generiert, die mit dem Perforce-Server synchronisiert sind. Git- und Perforce-Mitarbeiter können in Harmonie am selben Code arbeiten, meist unabhängig von der Wahl der Versionskontrolle durch ihre Mitarbeiter. Git Fusionen 13.3 ist verfügbar von der Perforce-Website. Es muss zwar vom Perforce-Administrator installiert werden, aber wenn Sie es installieren, werden Sie feststellen, dass seine Repository-Slicing-Funktion als Git-Benutzer ziemlich nützlich sein kann.

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

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

Einige Terminologieunterschiede zum Sortieren

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

Das erste ist Auschecken. In Git erhalten Sie so eine Kopie des Codes aus einem bestimmten Zweig in Ihren Arbeitsbereich. In Perforce nennen wir das a synchronisieren von der Kommandozeile oder von unserem GUI P4V "Get Latest Revision". Perforce verwendet das Wort Auschecken von P4V oder p4 edit von der Befehlszeile aus bedeutet, dass Sie eine Datei vom Versionskontrollsystem aus ändern möchten. Im Rest dieses Dokuments verwende ich Checkout im Sinne von Perforce.

Die zweite ist Git verpflichten gegen Perforce einreichen. Wo Sie in Git engagieren würden, werden Sie in Perforce einreichen. Da alle Vorgänge für den freigegebenen Perforce-Versionsdienst ausgeführt werden, gibt es für Perforce keine Entsprechungen git push. Genauso haben wir kein pull; Der Sync-Befehl von oben kümmert sich darum, Dateien für uns zu bekommen. Es gibt kein Konzept für eine reine lokale Übermittlung in Perforce, es sei denn, Sie verwenden unser im Folgenden 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 für Dateien, die auf einem Perforce-Server gespeichert sind. 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 synonym verwenden, aber sie unterscheiden sich. Eine Perforce-Site kann mehrere Server auswählen, aber meistens befinden sich alle Dateien auf einem Server.

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

Die Arbeitsbereichansicht gibt die Menge der Dateien im Depot an, die dem lokalen Computer zugeordnet werden sollen. Dies ist wichtig, da die Wahrscheinlichkeit groß ist, dass nicht alle Dateien auf dem Server verfügbar sind. In einer Arbeitsbereichansicht können Sie nur die Gruppe auswählen, die Ihnen wichtig ist. Es ist wichtig zu beachten, dass ein Arbeitsbereich Inhalte aus mehreren Depots zuordnen kann, aber nur Inhalt von einem Server zuordnen kann.

Um in dieser Hinsicht Perforce mit Git zu vergleichen, wählen Sie mit Git die Menge von Git-Repos aus, an denen Sie interessiert sind. Jedes Repo ist in der Regel eng begrenzt, um nur verwandte Dateien zu enthalten. Der Vorteil davon ist, dass es keine Konfiguration für Sie gibt; Du machst einen Git Klon von den Dingen die dir wichtig sind und du bist fertig. Dies ist besonders nützlich, wenn Sie nur mit einem oder zwei Repositories arbeiten. Mit Perforce müssen Sie ein wenig Zeit damit verbringen, die gewünschten Code-Teile auszuwählen und auszuwählen.

Viele Perforce-Shops verwenden Streams, die automatisch eine Arbeitsbereichansicht generieren können, oder sie generieren die Ansicht mithilfe von Skripts oder Vorlagenarbeitsbereichen. Gleichermaßen überlassen viele ihren Benutzern, ihre Arbeitsbereiche selbst zu generieren. Ein Vorteil der Möglichkeit, mehrere Module in einem Arbeitsbereich abzubilden, besteht darin, dass Sie mehrere Codemodule in einem einzigen Check-in ändern können. Sie können sicherstellen, dass jeder Benutzer mit einem ähnlichen Client, der sich mit Ihrem Check-in synchronisiert, den gesamten Code im richtigen Status hat. Dies kann jedoch auch zu übermäßigem Code führen. Die erzwungene Trennung von Git kann zu einer besseren Modularität führen. Zum Glück kann Perforce auch strenge Modularität unterstützen. Es kommt darauf an, wie Sie das Tool verwenden.

Warum Arbeitsbereiche?

Ich denke, wenn man von Git kommt, ist es leicht zu glauben, dass das ganze Workspace-Konzept viel mehr Mühe macht, als es wert ist. Im Vergleich zum Klonen einiger Git-Repos ist dies zweifellos wahr. Wo Workspaces glänzen und Perforce nach all den Jahren immer noch im Geschäft ist, ist, dass Workspaces eine fantastische Möglichkeit darstellen, mehrere Millionen Dateiprojekte für Entwickler herunterzuspielen, während gleichzeitig Build und Release die gesamte Quelle zusammenziehen eine maßgebliche Quelle. Arbeitsbereiche sind einer der Hauptgründe, warum Perforce so gut skalierbar ist.

Arbeitsbereiche sind auch insofern interessant, als das Layout von Dateien im Depot und das Layout auf dem Computer des Benutzers bei Bedarf variieren können. Viele Firmen organisieren ihr Depot, um die Organisation ihres Unternehmens zu reflektieren, so dass es für die Menschen leicht ist, Inhalte nach Geschäftsbereichen oder Projekten zu finden. Ihr Build-System könnte sich jedoch weniger um diese Hierarchie kümmern. Der Arbeitsbereich ermöglicht es ihnen, ihre Depothierarchie auf die für ihre Tools sinnvolle Weise neu zu ordnen. Ich habe auch gesehen, dass dies von Unternehmen genutzt wird, die extrem unflexible Build-Systeme verwenden, die Code in sehr spezifischen Konfigurationen benötigen, die für den Menschen völlig verwirrend sind. Arbeitsbereiche ermöglichen diesen Unternehmen eine Quellenhierarchie, die von Benutzern navigierbar ist, während ihre Erstellungstools 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. Dadurch kann das System beim Synchronisieren die korrekten Dateien an den Benutzer senden, ohne die Dateien prüfen 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 sehr beliebt in Branchen, die sehr strenge Prüfungsregeln haben; Perforce-Administratoren können problemlos verfolgen und protokollieren, welche Entwickler welche Dateien synchronisiert haben.

Weitere Informationen zur vollen Leistung von Perforce-Arbeitsbereichen P4 konfigurieren.

Expliziter Checkout vs. impliziter Checkout

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

Die gute Nachricht ist, dass Sie mit Perforce arbeiten können, wenn Sie dies wünschen. In Perforce können Sie die Option "Allwrite" in Ihrem Arbeitsbereich festlegen. Dies teilt Perforce mit, dass alle Dateien mit dem schreibbaren Bit auf die Festplatte geschrieben werden sollen. Sie können dann jede gewünschte Datei ändern, ohne Perforce ausdrücklich zu informieren. Damit Perforce diese Änderungen abstimmen kann, können Sie "p4 status" ausführen. Es öffnet Dateien zum Hinzufügen, Bearbeiten und Löschen entsprechend. Wenn Sie auf diese Weise arbeiten, sollten Sie "p4 update" anstelle von "p4 sync" verwenden, um neue Versionen vom Server zu erhalten. "p4 update" prüft vor der Synchronisierung auf Änderungen, so dass Ihre lokalen Änderungen nicht verfälscht werden, wenn Sie noch nicht "p4 status" ausgeführt haben.

Warum explizite Kasse?

Eine Frage, die ich häufig erhalte, lautet: "Warum sollten Sie jemals explizite Kasse verwenden?" Es kann auf den ersten Blick scheinen, eine verrückte Entwurfsentscheidung zu sein, aber ausdrückliches Auschecken hat einige starke Vorteile.

Ein Grund für das explizite Auschecken ist, dass keine Dateien mehr auf Inhaltsänderungen überprüft werden müssen. Während bei kleineren Projekten das Berechnen von Hashwerten für jede Datei, um Unterschiede zu finden, ziemlich billig ist, haben viele unserer Benutzer Millionen von Dateien in einem Arbeitsbereich und / oder haben Dateien, die eine Größe von 100 Megabytes haben, wenn nicht sogar größer. Die Berechnung aller Hashes in diesen Fällen ist extrem zeitaufwendig. Durch das explizite Auschecken kann Perforce genau wissen, mit welchen Dateien es arbeiten muss. Dieses Verhalten ist einer der Gründe, warum Perforce in großen Dateiindustrien wie der Spiel-, Film- und Hardware-Industrie so beliebt ist.

Ein weiterer Vorteil ist, dass das explizite Auschecken eine Form der asynchronen Kommunikation bietet, mit der Entwickler im Allgemeinen wissen, an was ihren Kollegen gerade oder zumindest wo gearbeitet wird. Es kann Ihnen mitteilen, dass Sie möglicherweise vermeiden möchten, in einem bestimmten Bereich zu arbeiten, um einen unnötigen Konflikt zu vermeiden, oder Sie können darauf aufmerksam machen, dass ein neuer Entwickler im Team in Code eingedrungen ist, den sie vielleicht nicht benötigen bearbeitet werden. Meine persönliche Erfahrung ist, dass ich entweder in Git arbeite oder Perforce mit Allwrite für Projekte verwende, bei denen ich entweder der einzige Beitragszahler oder ein seltener Beitragszahler bin, und explizit auschecke, wenn ich eng mit einem Team arbeite. Zum Glück ist die Wahl dir.

Das explizite Auschecken funktioniert auch gut mit dem Perforce-Konzept der ausstehenden Ä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 Eimer für die Organisation der Arbeit verwenden. Zweige sind großartig, aber manchmal ist es schön, wenn Sie Ihre Arbeit in mehrere benannte Änderungen organisieren können, bevor Sie sie tatsächlich an den Server senden. Mit dem Perforce-Modell, das möglicherweise mehrere Zweige oder mehrere Projekte in einem Arbeitsbereich zusammenfasst, erleichtern ausstehende Änderungslisten die Organisation separater Änderungen.

Wenn Sie eine Entwicklungsumgebung 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, damit Sie nicht mehr selbst Kasse machen müssen.

Perforce Replacements für Git-Funktionen

  • git stash ==> p4 shelve
  • git local branching ==> entweder Perforieren Regale oder Aufgaben Filialen
  • git blame ==> p4 annotate oder Perforation Timelapse-Ansicht von der GUI

Arbeiten getrennt

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

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

2) Bearbeiten Sie die Dateien nach Belieben und verwenden Sie 'p4 status', um Perforce mitzuteilen, was Sie getan haben

Mit beiden obigen Optionen können Sie die Einstellung "allwrite" in Ihrem Arbeitsbereich verwenden, sodass 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 die Dateien auf Änderungen, bevor sie über 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 Ihrer Shell-Konfigurationsdatei festhalten, verwenden p4 set um sie unter Windows und OS X zu speichern, oder verwenden Sie eine Perforce-Konfigurationsdatei.

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, die Sie bearbeiten möchten, und ändern Sie sie

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

4) Übermitteln Sie es an den Server

p4 submit -d "A trivial edit"

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


265
2018-06-26 22:04



Es gibt wahrscheinlich nicht viele solcher Dokumente, 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 zu mappen, ist nicht der richtige Ansatz; Konzepte von zentralisierten vs. verteilten Revisionskontrollsystemen sind nicht gleich. Stattdessen werde ich einen typischen Workflow in Perforce beschreiben:

  1. Lauf p4 edit für jede Datei, 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. Ändern Sie Ihren Code.
  3. Lauf p4 change Erstellen eines Änderungssets Hier können Sie eine Beschreibung Ihrer Änderung erstellen und optional auch Dateien aus Ihrem Änderungssatz hinzufügen oder entfernen. Du kannst rennen p4 change CHANGE_NUMBER um die Beschreibung später bei Bedarf zu 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. Lauf p4 sync um die letzten Änderungen vom Server einzuholen.
  6. Lauf p4 resolve um Konflikte von der Synchronisierung zu lösen.
  7. Wenn Sie Ihre Änderungen übermitteln möchten, führen Sie sie aus p4 submit -c CHANGE_NUMBER.

Sie können verwenden p4 revert um die Änderungen in Dateien zurückzusetzen.

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

Wenn Sie Dateien bearbeiten müssen, die Sie bereits in einem anderen Changeset geöffnet haben, können Sie entweder einen separaten Perforce-Client erstellen oder Ihr vorhandenes Changeset für später speichern p4 shelve. (Nicht wie git stashDurch das Zurücksetzen werden die Dateien in Ihrer lokalen Struktur nicht zurückgesetzt. Sie müssen sie daher separat wiederherstellen.)


16
2018-06-25 20:18



Der größte Unterschied zwischen git und p4, den keine der vorhandenen Antworten anspricht, ist, dass sie unterschiedliche Abstraktionseinheiten verwenden.

  • In Git ist die Abstraktion die patch (aka diff, aka changeset). Ein commit in git ist im Wesentlichen die Ausgabe von running diff zwischen dem vorherigen und dem aktuellen Status der zu übertragenden Dateien.
  • In der Not ist die Abstraktion die Datei. Ein Commit in p4 ist der vollständige Inhalt der Dateien in dem 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 fließt aus diesem Unterschied. Das Verzweigen und Zusammenführen in Git ist schmerzlos, da aus der Perspektive der Git-Abstraktion jede Datei vollständig rekonstruiert werden kann, indem eine Reihe von Patches der Reihe nach angewendet wird, und daher zwei Zweige zusammengeführt werden müssen die nicht im Zielzweig zum Zielzweig in der richtigen Reihenfolge vorhanden sind (vorausgesetzt, es gibt keine Überlappungen auf beiden Zweigen).

Perforce-Filialen sind anders. Eine zwangsweise Verzweigungsoperation kopiert Dateien von einem Unterordner in einen anderen und markiert dann die Verknüpfung zwischen den Dateien mit Metadaten auf dem Server. So führen Sie eine Datei von einem Zweig zu einem anderen zusammen (integration in Zwangsbedingungen), wird zwangsläufig auf die vollständiger Inhalt der Datei an der 'Kopf' von der Quelle Zweig und der vollständiger Inhalt der Datei an der Spitze des Zielzweiges und ggf. mit einem gemeinsamen Vorfahren verschmelzen. Es ist nicht in der Lage, Patches wie Git-Dose nacheinander anzuwenden, was bedeutet, dass manuelle Zusammenführungen häufiger vorkommen (und dazu neigen, schmerzhafter zu sein).


13
2018-02-09 13:06