it-swarm.com.de

Perforce für Git-Benutzer?

Es gibt eine Menge "Git für Perforce-Benutzer" -Dokumentation, aber anscheinend ist das Gegenteil nicht der Fall.

Ich habe bisher nur Git verwendet und vor kurzem einen Job begonnen, bei dem ich viel mit Perforce arbeiten muss und mich die meiste Zeit sehr verwirrt fühle. Die Konzepte, die ich von Git gewohnt bin, scheinen Perforce überhaupt nicht zuzuordnen.

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

160
Brennan Vincent

Daran habe ich in den letzten Wochen immer wieder gearbeitet. Es ist noch in der Entwicklung, 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. Als zwei Werkzeuge, die angeblich dasselbe tun, könnte ihr Ansatz unterschiedlicher nicht sein. Diese kurze Beschreibung soll neuen Perforce-Benutzern, die von Git kommen, 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 an, das Git-Repositorys generiert, die mit dem Perforce-Server synchronisiert sind. Git- und Perforce-Benutzer können in Harmonie am selben Code arbeiten, was sich größtenteils nicht auf die Versionskontrolle ihrer Kollegen auswirkt. Git Fusions 13.3 ist auf der Perforce-Website verfügbar. Es muss 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 von der Installation von Git Fusion überzeugen können, wird Git selbst mit einer Perforce-Bindung namens Git-P4 ausgeliefert, mit der Sie mit Git Dateien in einem Perforce-Arbeitsbereich ändern und senden 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 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 Checkout. In Git erhalten Sie auf diese Weise eine Kopie des Codes aus einem bestimmten Zweig in Ihren Arbeitsbereich. In Perforce nennen wir dies sync von der Kommandozeile oder von unserer GUI P4V "Get Latest Revision". Perforce verwendet das Wort checkout von P4V oder p4 edit über die Befehlszeile bedeutet, dass Sie eine Datei über das Versionskontrollsystem ändern möchten. Im Rest dieses Dokuments werde ich Checkout im Perforce-Sinne des Wortes verwenden.

Der zweite ist Git commit versus Perforce submit. Wo Sie in Git ein Commit durchführen würden, werden Sie in Perforce einreichen. Da alle Vorgänge für den gemeinsam genutzten Perforce-Versionsdienst ausgeführt werden, verfügt Perforce nicht über eine Entsprechung für git Push. Ebenso haben wir kein pull; Der Synchronisierungsbefehl von oben sorgt dafür, dass Dateien für uns abgerufen werden. Es gibt kein Konzept für eine reine lokale Übermittlung in Perforce, es sei denn, Sie verwenden unser P4Sandbox-Tool, das im Folgenden kurz beschrieben wird.

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 werden Sie hören, dass Perforce-Benutzer Depot und Server austauschbar verwenden, diese unterscheiden sich jedoch. 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 Gruppe von Dateien im Depot an, die dem lokalen Computer zugeordnet werden sollen. Dies ist wichtig, da möglicherweise nicht alle Dateien auf dem Server verfügbar sein sollen. In einer Arbeitsbereichansicht können Sie nur den Satz auswählen, den Sie interessieren. Es ist wichtig zu beachten, dass ein Arbeitsbereich Inhalte aus mehreren Depots zuordnen kann, jedoch nur Inhalte von einem Server.

Um diesbezüglich Perforce mit Git zu vergleichen, wählen Sie mit Git die Menge der Git-Repos aus, an denen Sie interessiert sind. Jedes Repo ist im Allgemeinen eng begrenzt, um nur verwandte Dateien zu enthalten. 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 dann hilfreich, wenn Sie nur mit einem oder zwei Repositorys arbeiten. Bei Perforce müssen Sie einige Zeit damit verbringen, die gewünschten Codebausteine ​​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 viele verlassen 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 Eincheckvorgang ändern können. Sie können sicher sein, dass jeder mit einer ähnlichen Client-Ansicht, der mit Ihrem Einchecken synchronisiert, den gesamten Code im richtigen Zustand 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 möchten.

Warum Arbeitsbereiche?

Ich denke, wenn man von Git kommt, ist es leicht zu spüren, dass das gesamte Arbeitsbereichskonzept mehr Ärger bedeutet, als es wert ist. Im Vergleich zum Klonen einiger Git-Repos ist dies zweifellos der Fall. 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 zusammenzufassen und gleichzeitig das Erstellen und Freigeben aller Quellen zu vereinfachen eine maßgebliche Quelle. Arbeitsbereiche sind einer der Hauptgründe, warum Perforce so gut skaliert werden kann.

Arbeitsbereiche sind auch insofern von Vorteil, als das Layout der Dateien im Depot und das Layout auf dem Computer des Benutzers bei Bedarf variieren können. Viele Unternehmen richten ihr Depot so ein, dass es der Organisation ihres Unternehmens entspricht, so dass die Mitarbeiter Inhalte nach Geschäftsbereichen oder Projekten leicht finden können. Ihr Build-System kümmert sich jedoch nicht weniger um diese Hierarchie. Über den Arbeitsbereich können sie ihre Depothierarchie neu zuordnen, wie es für ihre Tools sinnvoll ist. Ich habe dies auch bei Unternehmen gesehen, 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 eine von Menschen navigierbare Quellhierarchie haben, während ihre Build-Tools die von ihnen benötigte Struktur erhalten.

Arbeitsbereiche in Perforce werden nicht nur zum Zuordnen der Dateigruppen verwendet, mit denen ein Benutzer arbeiten möchte, sondern sie werden auch vom Server verwendet, um genau zu verfolgen, welche Revisionen jeder Datei vom Benutzer synchronisiert wurden. 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 nachverfolgen und protokollieren, welche Entwickler welche Dateien synchronisiert haben.

Weitere Informationen zur vollen Leistungsfähigkeit von Perforce-Arbeitsbereichen finden Sie unter Konfigurieren von P4 .

Explizite Prüfung gegen implizite Prüfung

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

Die gute Nachricht ist, dass Sie auf Wunsch in Perforce mit einem Workflow im Git-Stil 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 eine beliebige 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, möchten Sie "p4 update" anstelle von "p4 sync" verwenden, um neue Revisionen vom Server abzurufen. "p4 update" sucht vor dem Synchronisieren nach Änderungen, sodass Ihre lokalen Änderungen nicht beeinträchtigt werden, wenn Sie noch nicht "p4 status" ausgeführt haben.

Warum explizite Kasse?

Ich erhalte häufig die Frage, warum Sie jemals die explizite Kaufabwicklung verwenden möchten. Es kann auf den ersten Blick wie eine verrückte Designentscheidung erscheinen, aber das explizite Auschecken hat einige mächtige Vorteile.

Ein Grund für die Verwendung des expliziten Auscheckens besteht darin, dass keine Dateien mehr nach Inhaltsänderungen durchsucht werden müssen. Während bei kleineren Projekten das Berechnen von Hashes für jede Datei zum Auffinden von Unterschieden ziemlich billig ist, haben viele unserer Benutzer Millionen von Dateien in einem Arbeitsbereich und/oder Dateien, die Hunderte von Megabyte groß sind, wenn nicht sogar größer. Das Berechnen aller Hashes in diesen Fällen ist äußerst zeitaufwändig. Durch das explizite Auschecken weiß Perforce genau, mit welchen Dateien es arbeiten muss. Dieses Verhalten ist einer der Gründe, warum Perforce in großen Dateiindustrien wie der Spiel-, Film- und Hardwareindustrie so beliebt ist.

Ein weiterer Vorteil ist, dass das explizite Auschecken eine Form der asynchronen Kommunikation bietet, mit der Entwickler im Allgemeinen wissen, woran ihre Kollegen arbeiten, oder zumindest, wo. Es kann Ihnen mitteilen, dass Sie möglicherweise vermeiden möchten, in einem bestimmten Bereich zu arbeiten, um unnötige Konflikte zu vermeiden, oder es kann Sie auf die Tatsache aufmerksam machen, dass ein neuer Entwickler im Team in Code gewandert ist, den er möglicherweise nicht benötigt zu bearbeiten. Persönlich habe ich die Erfahrung gemacht, dass ich entweder in Git arbeite oder Perforce mit Allwrite bei Projekten verwende, bei denen ich entweder der einzige oder ein seltener Mitwirkender bin. Wenn ich eng mit einem Team zusammenarbeite, muss ich das explizit auschecken. Zum Glück liegt die Wahl bei Ihnen.

Explizites Auschecken passt auch gut zum Perforce-Konzept ausstehender Änderungslisten. Ausstehende Änderungslisten sind Bereiche, in denen Sie Ihre geöffneten Dateien ablegen 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 hilfreich, Ihre Arbeit in mehrere benannte Änderungen zu unterteilen, bevor Sie sie tatsächlich an den Server senden. Mit dem Perforce-Modell, bei dem möglicherweise mehrere Zweige oder mehrere Projekte in einem Arbeitsbereich zugeordnet werden, können ausstehende Änderungslisten die Organisation einzelner Änderungen vereinfachen.

Wenn Sie eine IDE für Entwicklungen 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 bearbeiten sie und müssen nicht mehr selbst auschecken.

Perforce-Ersetzungen für Git-Funktionen

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

Arbeit getrennt

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

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

2) Bearbeiten Sie die Dateien nach Ihren Wünschen und teilen Sie Perforce mit, 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, möchten Sie den Befehl "p4 update" verwenden, um neue Dateien anstelle von "p4 sync" zu synchronisieren. "p4 update" überprüft Dateien vor dem Synchronisieren auf Änderungen.

Perforce-Schnellstart

Alle folgenden Beispiele werden über die Befehlszeile ausgeführt.

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 übernehmen, indem Sie p4 set, um sie unter Windows und OS X zu speichern oder eine Perforce-Konfigurationsdatei zu 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 p4 help simple, um die grundlegenden Befehle anzuzeigen, die Sie für die Arbeit mit Perforce benötigen.

305
Matt

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

  • In git ist die Abstraktion der Patch (aka diff, aka changeset). Ein Commit in Git ist im Wesentlichen die Ausgabe von diff zwischen dem vorherigen und dem aktuellen Status der Dateien, für die ein Commit ausgeführt wird.
  • Per Zufall ist die Abstraktion 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 auf Dateibasis 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 der Perspektive der Git-Abstraktion jede Datei vollständig rekonstruiert werden kann, indem eine Reihe von Patches der Reihe nach angewendet wird. Um also zwei Zweige zusammenzuführen, müssen Sie nur alle Patches auf den Quellzweig anwenden die im Zielzweig nicht in der richtigen Reihenfolge zum Zielzweig vorhanden sind (vorausgesetzt, es gibt keine Patches auf beiden Zweigen, die sich überlappen).

Perforce-Niederlassungen sind unterschiedlich. Bei einer Verzweigungsoperation werden die Dateien von einem Unterordner in einen anderen kopiert und anschließend die Verknüpfung zwischen den Dateien mit den Metadaten auf dem Server markiert. Um eine Datei von einem Zweig in einen anderen zusammenzuführen (integration in Bezug auf Perforce), überprüft Perforce den vollständigen Inhalt der Datei unter den 'Kopf' des Quellzweigs und den vollständigen Inhalt der Datei am Kopf des Zielzweigs und, falls erforderlich, unter Verwendung eines gemeinsamen Vorfahren zusammenführen. Es ist nicht möglich, Patches wie git can einzeln anzuwenden, was bedeutet, dass manuelle Zusammenführungen häufiger vorkommen (und in der Regel schmerzhafter sind).

20
damian

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

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

  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. Nehmen Sie Ihre Codeänderungen vor.
  3. Lauf p4 change, um ein Änderungsset zu erstellen. Hier können Sie eine Beschreibung Ihrer Änderung erstellen und optional auch Dateien zu Ihrem Änderungssatz hinzufügen oder daraus entfernen. Du kannst rennen p4 change CHANGE_NUMBER, um die Beschreibung später bei Bedarf zu bearbeiten.
  4. Sie können bei Bedarf weitere Codeänderungen vornehmen. Wenn Sie andere Dateien hinzufügen/bearbeiten/löschen müssen, können Sie p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
  5. Lauf p4 sync, um die neuesten Änderungen vom Server abzurufen.
  6. Lauf p4 resolve, um Konflikte bei der Synchronisierung zu lösen.
  7. Wenn Sie bereit sind, Ihre Änderung zu übermitteln, führen Sie p4 submit -c CHANGE_NUMBER.

Sie können p4 revert, um Ihre Änderungen an Dateien rückgängig zu machen.

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

Wenn Sie feststellen, dass Sie Dateien bearbeiten müssen, die bereits in einem anderen Änderungssatz geöffnet sind, können Sie entweder einen separaten Perforce-Client erstellen oder Ihren vorhandenen Änderungssatz über p4 shelve. (Nicht wie git stash, Shelving setzt die Dateien in Ihrem lokalen Baum nicht zurück, daher müssen Sie sie separat zurücksetzen.)

18
jamesdlin