Versuchen Sie, "@all" an den Dateipfad anzuhängen. Zum Beispiel ergibt sich ein Repo-Single-Revision für mich:
python /usr/share/doc/git-core/contrib/fast-import/git-p4 clone --destination=master-pom \
//depot/services/master-pom/trunk/...
Dieser Befehl die vollständige Geschichte importiert:
python /usr/share/doc/git-core/contrib/fast-import/git-p4 clone --destination=master-pom \
//depot/services/master-pom/trunk/[email protected]
ich das Beispiel git-p4 versucht, mit gab aber aus mehreren Gründen auf und schrieb meine eigene Fast-Import-Pumpe. Es ist eine Weile her, dass einige der Probleme jetzt behoben wurden: aber git-p4 hatte Probleme mit großen Änderungslisten (wie die erste Erstellung einer Verzweigung) (obwohl die Verwendung der Client-Spezifikation geholfen haben könnte, tue ich nicht denke, ich habe es versucht) und Dateien mit dem "+ S" Dateityp-Modifikator (das ist Bad And Evil, aber wir haben es verwendet). Und mein Python-Fu war nicht dazu in der Lage, die Probleme, die ich hatte, zu beheben.
EDIT: seit jemand danach gefragt hat, hier ist es.
https://github.com/araqnid/p4utils hat einige p4 Dinge, von denen p4-git-xfer der p4-> git (Einweg-) Replikator ist. Es hat jedoch einige Probleme, da es sich hauptsächlich um ein persönliches Handy-Tool und nicht um eine echte Infrastruktur handelt.
Erste Schritte:
p4-git-xfer clone -d $PWD/dictionary.git -n //depot/services/midoffice/dictionary/... \
trunk 'release/*' 'branch/*' \
trunk=master release/*=r* branch/*=dev/*
wird, dass notgedrungen Weg zu einem bloßen "dictionary.git" klonen. Die ersten Argumente nach dem Basispfad sind "Verzweigungsspezifikationen", die dem Replikator mitteilen, wo sich Zweige unter der Basis befinden. Die späteren (mit '=' Symbolen) sind "Spiegelspezifikationen", die dem Replikator mitteilen, wie lokale Zweige aus den importierten erzeugt werden. Die Zweigspezifikationen bewirken, dass "refs/remotes/p4/trunk", "refs/remotes/p4/release/1.0" usw. erstellt werden. Die Mirror Specs zwingen "refs/heads/master" zu spiegeln "refs/remotes/p4/trunk", "refs/heads/r1.0" spiegeln "refs/remotes/p4/release/1.0" usw. Es war beabsichtigt als eine Möglichkeit, um nur bestimmte Zweige von denen auszuwählen, die repliziert wurden, um an Klone weitergegeben zu werden.
Es wird versuchen, zu erkennen, wie eine Verzweigung erstellt wird, aber das ist bei Perforce sowieso ein wenig raten. Außerdem versucht es überhaupt kein Filial-Tracking, auch ganze Branches werden nicht als solche ausgegeben, sorry.
Nach dem ersten Klon führt das Ausführen von aus dem Git-Replikat eine inkrementelle Aktualisierung durch. Die High-Water-Mark-Änderungsliste wird innerhalb des Git Repo von marks/p4 übernommen. Dies ist eine Markendatei, die schnell importiert werden kann. Wenn Sie also eine ausgeklügelte Fußarbeit machen, wie zum Beispiel die Verwendung von Filter-Branch, um Dinge neu zu schreiben, müssen Sie dies möglicherweise auch aktualisieren.
Es ist nicht schön, und hat einige mittelschwere bis ernsthafte Probleme; Ich benutze es hauptsächlich zu meiner eigenen Bequemlichkeit, um mich von Perforce-Problemen zu isolieren, nicht als alltägliche Komponente kritischer Infrastrukturen. Es ist unidirektional: Ich verwende das p4-am-Skript im Allgemeinen, um Patches anzuwenden, die von git format-patch erstellt wurden. Das selbst funktioniert nur meist mit allgemeiner Parsing Bösartigkeit, Problemen mit dem End-of-Datei Zeilenumbrüchen, binären Veränderungen usw.
Ist Ihr p4-Import-Skript öffentlich? Wenn ja, hätten Sie etwas dagegen, es zu teilen? – joce