git-p4 migrieren Zweige in verschiedenen Unterverzeichnissen

Question

Ich möchte Quellcode-Baum von notforce zu git migrieren. Der Quellcode enthält mehrere Dev-Zweige, die über das Perforce-Depot verstreut sind, und nicht notwendigerweise im selben Verzeichnis. zum Beispiel ist die Struktur so etwas wie diese -

//depot/dev/project/master 
//depot/dev/project/branch1 
//depot/dev/project/branch2 
//depot/dev/sub-project/branch3 
//depot/dev/sub-project/branch4 
//depot/patch-project/branch5 
//depot/patch-project/special/developern/branch6 

ich aber git-p4 Dokumentation https://git-scm.com/docs/git-p4 BRANCHEN-Erfassungsabschnitt ging und auch Ähnliche Artikel http://forums.perforce.com/index.php?/topic/1395-git-p4-and-multiple-branches/.

Ich bin in der Lage Zweig für die mit der Geschichte zu migrieren, die unter unmittelbar Eltern sind wie

//depot/dev/project/branch1 and 
//depot/dev/project/branch2 

Was ich nicht in der Lage bin, ist zu erreichen, wie kann ich alle sechs Zweige zusammen auf einmal migrieren.

Ich habe versucht, die Migration auf // Depot @ alle Ebene nach Angabe der Branch-Spezifikationen, aber es ist fehlgeschlagen seit perforce Server ist riesig, gibt es entweder maxresults Ausnahme oder Session-Timeout. Kann jemand bitte erläutern, wie dieses Szenario gehandhabt werden kann?

Eine weitere Option, die ich sehe, ist, Zweige separat zu migrieren (ein Zweig zu einem Git Repo) und dann diese alle Zweige in ein neues Git Repo zusammenführen. Ich bin mir nicht sicher, ob dies das ist, was Einfluss/Nachteil haben wird.

Thanks and Regards, 
Amar Kumbhar. 

Answer 1

Zusammenfassung: Es funktioniert, git-p4 ist ein großartiges Werkzeug, sehr intelligent, kommt mit vielen konfigurierbaren Optionen. Mehrere Verzweigungen, die über den Depotbaum verstreut sind, wurden erfolgreich migriert. Wir müssen den Import auf dem obersten (obersten) Verzeichnis ausführen, das alle Unterverzeichnisse oder Zweige von Interesse abdeckt.Für einen effizienten Betrieb wird empfohlen, - changesfile Option zu verwenden, um die zu importierenden Änderungslisten explizit anzugeben. Verwenden Sie auch git-p4.branchUser und git-p4.branchList explizit branchspecs angeben.

Details: Hier zeige ich die Einstellungen, die für mich gearbeitet haben. Es kann einen besseren Weg geben, um das Ziel zu erreichen.

Perforce Depotstruktur: (wie in Frage erwähnt)

Perforce-Client: Die auf höchstem (oberstes) p4 Verzeichnis eingestellt ist. Dies ist sehr wichtig, ansonsten kann git-p4 Änderungslisten (eingeschränkt aufgrund der Client-Ansicht) als leere Commits ausschließen.

//depot/... //myp4client/... 

Perforce branchspecs: habe ich eine einzige branchspec, dass meine alle Zweige Abhängigkeit abdeckt (Eltern/Kind) Informationen

$ p4 branch -o test1 | grep "//" 

    //depot/dev/project/master/... //depot/dev/project/branch1/... 
    //depot/dev/project/master/... //depot/dev/project/branch2/... 
    //depot/dev/project/branch1/... //depot/dev/sub-project/branch3/... 
    //depot/dev/project/branch1/... //depot/dev/sub-project/branch4/... 
    //depot/dev/project/master/... //depot/patch-project/branch5/... 
    //depot/patch-project/branch5/... //depot/patch-project/special/developern/branch6 

git-p4 config-Artikel: Als nächstes ich Setup ein leeres git-Repository und folgende Konfigurationselemente.

mkdir workdir 
cd workdir 
git init 

(** notgedrungen Variablen)

git config git-p4.user myp4user 
git config git-p4.passwowrd myp4password 
git config git-p4.port myp4port 
git config git-p4.client myp4client 

(** Kraft notgedrungen Client-Spezifikation zu verwenden)

git config git-p4.useClientSpec true 
git config git-p4.client myp4client 

(** beschränken branchspecs erstellt von mir nur erkunden)

git config git-p4.branchUser myp4user 

(** Zweig informieren ation, Abhängigkeitsbeziehung wird interessanterweise nur Nachname (Verzeichnisname in Zweigpfad) erforderlich zu erwähnen, git-p4 erkennt automatisch/pick was völlig die Zweignamen erweitert, dh erforderlich ist)

git config git-p4.branchList master:branch1 
git config --add git-p4.branchList master:branch2 
git config --add git-p4.branchList branch1:branch3 
git config --add git-p4.branchList branch1:branch4 
git config --add git-p4.branchList master:branch5 
git config --add git-p4.branchList branch5:branch6 

Änderungslisten-Datei: Als nächstes sammelte ich alle Änderungslisten für alle Zweige, die ich migriere.

p4 changes //depot/dev/project/master/... | cut -d' ' -f2 >> master.txt 
p4 changes //depot/dev/project/branch1/... | cut -d' ' -f2 >> master.txt 
p4 changes //depot/dev/project/branch2/... | cut -d' ' -f2 >> master.txt 
p4 changes //depot/dev/sub-project/branch3/... | cut -d' ' -f2 >> master.txt 
p4 changes //depot/dev/sub-project/branch4/... | cut -d' ' -f2 >> master.txt 
p4 changes //depot/patch-project/branch5/... | cut -d' ' -f2 >> master.txt 
p4 changes //depot/patch-project/special/developern/branch6/... | cut -d' ' -f2 >> master.txt 

sort -n master.txt | uniq > master_sorted.txt 

Import: Schließlich lief ich die, wie unten Import, I "sync" verwendet und Klon nicht.

cd workdir 
../git-p4.py sync //depot/... --detect-branches --verbose --changesfile /home/myp4user/master_sorted.txt 

Auf kleinere Depots „../git-p4.py sync // depot @ alle --detect-Filialen --verbose„soll auch funktionieren, in diesem Fall keine Notwendigkeit Änderungslisten-Datei zu erstellen (früher Schritt)

Sobald der Import abgeschlossen ist, kann ich sehen, dass git-p4 alle Remote-Perforation-Zweige in einem einzigen Git-Repository erstellt hat.

git branch -a 
    remotes/p4/depot/dev/project/master 
    remotes/p4/depot/dev/project/branch1 
    remotes/p4/depot/dev/dev/project/branch2 
    remotes/p4/depot/dev/dev/sub-project/branch3 
    remotes/p4/depot/dev/dev/sub-project/branch4 
    remotes/p4/depot/patch-project/branch5 
    remotes/p4/depot/patch-project/special/developern/branch6 

Dann habe ich Ortsvereine von entfernten p4 Filialen

git checkout -b master remotes/p4/depot/dev/project/master 
    git checkout -b branch1 remotes/p4/depot/dev/project/branch1 
    git checkout -b branch2 remotes/p4/depot/dev/dev/project/branch2 
    git checkout -b branch3 remotes/p4/depot/dev/dev/sub-project/branch3 
    git checkout -b branch4 remotes/p4/depot/dev/dev/sub-project/branch4 
    git checkout -b branch5 remotes/p4/depot/patch-project/branch5 
    git checkout -b branch6 remotes/p4/depot/patch-project/special/developern/branch6 

Als nächstes habe ich einfach eine Remote Herkunft und schob den Code in git Repo hinzugefügt.
Danke für verschiedene Hinweise/Hilfe in stackoverflow und online verfügbar.

Answer 2

Die neueste Version von git-p4 sollte nicht maxresults Ausnahmen gegeben berichtet, dass es maximal 500 Änderungen zu einem Zeitpunkt abgerufen werden. Sie können versuchen, diesen Wert mit dem Argument --changes-block-size zu ändern, das Ihnen dabei helfen könnte, das von Ihnen gemeldete Problem zu beheben.

Hier ist die Beschreibung dieses Argument ist, wie here zu sehen ist:

--changes-block-size <n>:: 
    The internal block size to use when converting a revision 
    specifier such as '@all' into a list of specific change 
    numbers. Instead of using a single call to 'p4 changes' to 
    find the full list of changes for the conversion, there are a 
    sequence of calls to 'p4 changes -m', each of which requests 
    one block of changes of the given size. The default block size 
    is 500, which should usually be suitable. 

Answer 3

stand ich ein ähnliches Problem vor und in meinem Fall hatte ich eine Abhilfe zu finden, die die, die Sie ist beschrieben, geklont ich je verzweigen Sie in sein eigenes Git Repo.

Schon damals hatten einzelne Zweige zu viele Objekte und die P4-Admins waren nicht bereit, das Limit für die angeforderten Objekte zu erhöhen, also musste ich auch die Menge der Geschichte begrenzen, die ich geklont habe.

Für inaktive Zweige würde ich nur die neueste Version klonen und den gesamten Verlauf verwerfen.

Für mehr aktive Zweige würde ich von 4-6 Wochen der Geschichte halten.

Das heißt, Sie müssen manuell herauszufinden, was die CL-Nummern sind für die Menge der Geschichte, die Sie behalten möchten:

Von git-p4 docs (Abschnitt: DEPOT PATH SYNTAX):

$ git p4 clone //depot/my/project@1,6 # Import only changes 1 through 6.