git-svn - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

git-svn - Bidirektionaler Betrieb zwischen einem Subversion-Repository und Git

ZUSAMMENFASSUNG

git svn [Optionen] [Argumente]

BESCHREIBUNG

git svn ist ein einfacher Kanal für Changesets zwischen Subversion und Git. Es bietet eine
bidirektionaler Fluss von Änderungen zwischen einem Subversion- und einem Git-Repository.

git svn kann ein Standard-Subversion-Repository verfolgen, indem man den üblichen
Layout "trunk/branches/tags" mit der Option --stdlayout. Es kann auch Zweigen folgen und
Tags in jedem Layout mit den Optionen -T/-t/-b (siehe Optionen zu init unten, und auch die
klonen Befehl).

Sobald ein Subversion-Repository verfolgt wurde (mit einer der oben genannten Methoden), wird das Git-Repository
kann von Subversion aktualisiert werden durch die holen Befehl und Subversion von Git aktualisiert durch die
dcommit Befehl.

BEFEHLE

init
Initialisiert ein leeres Git-Repository mit zusätzlichen Metadatenverzeichnissen für git svn.
Die Subversion-URL kann als Befehlszeilenargument oder als vollständige URL angegeben werden
Argumente zu -T/-t/-b. Optional kann das zu bearbeitende Zielverzeichnis angegeben werden
als zweites Argument. Normalerweise initialisiert dieser Befehl das aktuelle Verzeichnis.

-T , --trunk= , -T , --tags= ,
-B , --branches= , -s, --stdlayout
Dies sind optionale Befehlszeilenoptionen für init. Jedes dieser Flags kann auf zeigen
ein relativer Repository-Pfad (--tags=project/tags) oder eine vollständige URL
(--tags=https://foo.org/project/tags). Sie können mehr als ein --tags und/oder . angeben
--branches-Optionen, falls Ihr Subversion-Repository Tags oder Branches platziert
unter mehreren Pfaden. Die Option --stdlayout ist eine Kurzform der Einstellung
trunk,tags,branches als relative Pfade, was der Subversion-Standard ist. Wenn überhaupt
der anderen Optionen ebenfalls angegeben sind, haben sie Vorrang.

--keine-Metadaten
Setze die keineMetadaten Option in der [svn-remote]-Konfiguration. Diese Option ist nicht
empfohlen, bitte lesen Sie die svn.noMetadaten Abschnitt dieser Manpage vor der Verwendung
diese Option.

--use-svm-props
Setze die Verwenden Sie SvmProps Option in der [svn-remote]-Konfiguration.

--use-svnsync-props
Setze die Verwenden Sie SvnsyncProps Option in der [svn-remote]-Konfiguration.

--rewrite-root=
Setze die Root umschreiben Option in der [svn-remote]-Konfiguration.

--rewrite-uuid=
Setze die UUID umschreiben Option in der [svn-remote]-Konfiguration.

--username=
Für Transporte, für die SVN die Authentifizierung übernimmt (http, https und einfaches svn),
den Benutzernamen angeben. Für andere Transporte (zB svn+ssh://) müssen Sie einschließen
der Benutzername in der URL, zB svn+ssh://foo@svn.bar.com/Projekt

--prefix=
Dies ermöglicht es, ein Präfix anzugeben, das den Namen der Fernbedienungen vorangestellt wird, wenn
Stamm/Zweige/Tags werden angegeben. Das Präfix enthält nicht automatisch a
nachgestellter Schrägstrich, also stellen Sie sicher, dass Sie einen in das Argument einfügen, wenn Sie das sind
wollen. Wenn --branches/-b angegeben ist, muss das Präfix einen abschließenden Schrägstrich enthalten.
Das Setzen eines Präfixes (mit einem nachgestellten Schrägstrich) wird in jedem Fall dringend empfohlen, da
Ihre SVN-Tracking-Refs befinden sich dann unter "refs/remotes/$prefix/"", welche is
kompatibel mit Git's besitzen Fernverfolgung ref Layout (refs/remotes/$remote/).
Das Festlegen eines Präfixes ist auch nützlich, wenn Sie mehrere Projekte verfolgen möchten, die sich teilen
ein gemeinsames Depot. Standardmäßig ist das Präfix auf . eingestellt Ursprung/.

Hinweis
Vor Git v2.0 war das Standardpräfix "" (kein Präfix). Das bedeutete, dass
SVN-Tracking-Refs wurden unter "refs/remotes/*" abgelegt, was nicht mit der Vorgehensweise kompatibel ist
Gits eigene Remote-Tracking-Refs sind organisiert. Wenn du noch das Alte willst
Standardmäßig erhalten Sie es, indem Sie --prefix "" in der Befehlszeile übergeben
(--prefix="" funktioniert möglicherweise nicht, wenn Ihr Perl-Getopt::Long < v2.37) ist.

--ignore-paths=
Bei Weitergabe an init or klonen dieser reguläre Ausdruck wird als Konfiguration beibehalten
Schlüssel. Sehen holen für eine Beschreibung von --ignore-paths.

--include-paths=
Bei Weitergabe an init or klonen dieser reguläre Ausdruck wird als Konfiguration beibehalten
Schlüssel. Sehen holen für eine Beschreibung von --include-Pfade.

--no-minimize-url
Beim Verfolgen mehrerer Verzeichnisse (mit --stdlayout, --branches oder --tags
Optionen), versucht git svn, sich mit dem Root (oder der höchsten zulässigen Ebene) zu verbinden.
des Subversion-Repositorys. Diese Standardeinstellung ermöglicht eine bessere Verfolgung des Verlaufs, wenn
ganze Projekte werden innerhalb eines Repositorys verschoben, können jedoch Probleme auf
Repositorys, in denen Lesezugriffsbeschränkungen gelten. Vorbeigehen
--no-minimize-url erlaubt git svn, URLs unverändert zu akzeptieren, ohne es zu versuchen
eine Verbindung zu einem übergeordneten Verzeichnis herstellen. Diese Option ist standardmäßig deaktiviert, wenn nur eine
URL/Zweig wird verfolgt (es würde wenig nützen).

holen
Holen Sie nicht abgerufene Revisionen von der Subversion-Fernbedienung, die wir verfolgen. Der Name des
Der Abschnitt [svn-remote "..."] in der Datei $GIT_DIR/config kann optional angegeben werden
Befehlszeilenargument.

Dadurch wird die rev_map bei Bedarf automatisch aktualisiert (siehe $GIT_DIR/svn/**/.rev_map.* in
im Abschnitt DATEIEN unten für Details).

--Ortszeit
Speichern Sie Git-Commit-Zeiten in der lokalen Zeitzone statt in UTC. Das macht git Log
(auch ohne --date=local) zeigen die gleichen Zeiten an, die svn log im local
Zeitzone.

Dies beeinträchtigt nicht die Zusammenarbeit mit dem Subversion-Repository, das Sie
geklont, aber wenn Sie möchten, dass Ihr lokales Git-Repository dies kann
mit dem lokalen Git-Repository einer anderen Person interoperieren, entweder verwenden Sie dies nicht
Option oder Sie sollten sie beide in derselben lokalen Zeitzone verwenden.

--Elternteil
Nur vom SVN-Elternteil des aktuellen HEAD abrufen.

--ignore-paths=
Dies ermöglicht es einem, einen regulären Perl-Ausdruck anzugeben, der das Überspringen von
alle passenden Pfade aus der Kasse von SVN. Der --ignore-paths Option sollte passen
für jeden holen (einschließlich automatischer Abrufe aufgrund von klonen, dcommit, zurückweisen, Usw.)
auf einem bestimmten Repository.

Konfigurationsschlüssel: svn-remote. .ignore-pfade

Wenn der Konfigurationsschlüssel ignore-paths gesetzt ist und auch die Befehlszeilenoption
gegeben, werden beide regulären Ausdrücke verwendet.

Beispiele:

Überspringe das "doc*"-Verzeichnis für jeden Abruf

--ignore-paths="^doc"

"Zweige" und "Tags" von Verzeichnissen der ersten Ebene überspringen

--ignore-paths="^[^/]+/(?:branches|tags)"

--include-paths=
Dies ermöglicht es einem, einen regulären Perl-Ausdruck anzugeben, der die Aufnahme bewirkt
von nur übereinstimmenden Pfaden aus der Kasse von SVN. Der --include-Pfade Option sollte
für jeden passen holen (einschließlich automatischer Abrufe aufgrund von klonen, dcommit, zurückweisen,
etc) auf einem bestimmten Repository. --ignore-paths hat Vorrang --include-Pfade.

Konfigurationsschlüssel: svn-remote. .include-Pfade

--log-window-size=
Bringen Protokolleinträge pro Anfrage beim Scannen des Subversion-Verlaufs. Die Standardeinstellung ist
100. Bei sehr großen Subversion-Repositorys können größere Werte für erforderlich sein
klonen/holen in angemessener Zeit abzuschließen. Aber zu große Werte können dazu führen, dass
höhere Speicherauslastung und Zeitüberschreitungen bei Anfragen.

klonen
Läuft init und holen. Es erstellt automatisch ein Verzeichnis basierend auf dem Basisnamen von
die an sie übergebene URL; oder wenn ein zweites Argument übergeben wird; es wird ein Verzeichnis erstellen
und arbeite darin. Es akzeptiert alle Argumente, die die init und holen Befehle
akzeptieren; mit Ausnahme von --fetch-all und --Elternteil. Nachdem ein Repository geklont wurde,
die holen Befehl kann Revisionen aktualisieren, ohne den Arbeitsbaum zu beeinträchtigen;
und den zurückweisen Befehl kann den Arbeitsbaum mit den neuesten aktualisieren
ändert.

--preserve-leere-Verzeichnisse
Erstellen Sie für jedes leere Verzeichnis eine Platzhalterdatei im lokalen Git-Repository
von Subversion geholt. Dies schließt Verzeichnisse ein, die durch das Entfernen leer werden
alle Einträge im Subversion-Repository (aber nicht das Verzeichnis selbst). Der
Platzhalterdateien werden ebenfalls verfolgt und entfernt, wenn sie nicht mehr benötigt werden.

--placeholder-filename=
Legen Sie den Namen von Platzhalterdateien fest, die von --preserve-empty-dirs erstellt wurden. Standard:
".gitignore"

zurückweisen
Dies ruft Revisionen vom SVN-Elternteil des aktuellen HEAD ab und stellt das aktuelle neu auf
(nicht an SVN gebunden) dagegen arbeiten.

Dies funktioniert ähnlich wie svn update oder git ziehen außer dass es die lineare Geschichte bewahrt
mit git zurückweisen statt git fusionieren für einfaches dcommiting mit git svn.

Dies akzeptiert alle Optionen, die git svn holen und git zurückweisen akzeptieren. Jedoch,
--fetch-all holt nur von der aktuellen [svn-remote] und nicht von allen [svn-remote]
Definitionen.

Like git zurückweisen; Dies erfordert, dass der Arbeitsbaum sauber ist und keine ungebundenen
ändert.

Dadurch wird die rev_map bei Bedarf automatisch aktualisiert (siehe $GIT_DIR/svn/**/.rev_map.* in
im Abschnitt DATEIEN unten für Details).

-l, --lokal
Holen Sie nicht aus der Ferne; nur laufen git zurückweisen gegen den zuletzt geholten Commit von
das Upstream-SVN.

dcommit
Übertragen Sie jeden Diff aus dem aktuellen Branch direkt in das SVN-Repository und dann
rebase oder reset (je nachdem ob ein Diff zwischen SVN und Head besteht oder nicht).
Dadurch wird für jeden Commit in Git eine Revision in SVN erstellt.

Wenn ein optionaler Git-Zweigname (oder ein Git-Commit-Objektname) als ein . angegeben wird
-Argument arbeitet der Unterbefehl für den angegebenen Zweig, nicht für den aktuellen Zweig.

Gebrauch von dcommit ist bevorzugt zu Set-Baum (unten).

--no-rebase
Nach dem Commit kein Rebase oder Reset durchführen.

--commit-url
Commit zu dieser SVN-URL (der vollständige Pfad). Damit sollen bestehende git svn
Repositories, die mit einer Transportmethode erstellt wurden (zB svn:// oder http:// für
anonymes Lesen) wiederzuverwenden, wenn einem Benutzer später Zugriff auf eine Alternative gewährt wird
Transportmethode (zB svn+ssh:// oder https://) für den Commit.

Konfigurationsschlüssel: svn-remote. .commiturl
Konfigurationsschlüssel: svn.commiturl (überschreibt alle svn-remote. .commiturl-Optionen)

Beachten Sie, dass die SVN-URL des Commiturl-Konfigurationsschlüssels den SVN-Zweig enthält. wenn du
Sie möchten lieber die Commit-URL für eine gesamte SVN-Repository-Nutzung festlegen
svn-Fernbedienung. .pushurl statt.

Es wird dringend davon abgeraten, diese Option für andere Zwecke zu verwenden (nicht fragen).

--mergeinfo=
Fügen Sie die angegebenen Merge-Informationen während des dcommit hinzu (zB
--mergeinfo="/branches/foo:1-10"). Alle SVN-Serverversionen können dies speichern
Informationen (als Eigenschaft), und svn-Clients ab Version 1.5 können
Gebrauch davon. Um Zusammenführungsinformationen aus mehreren Verzweigungen anzugeben, verwenden Sie ein einzelnes Leerzeichen
Zeichen zwischen den Zweigen (--mergeinfo="/branches/foo:1-10
/zweige/bar:3,5-6,8")

Konfigurationsschlüssel: svn.pushmergeinfo

Diese Option führt dazu, dass git-svn versucht, die
svn:mergeinfo-Eigenschaft im SVN-Repository, wenn möglich. Derzeit kann dies
nur durchgeführt werden, wenn nicht-schnelle Vorlauf-Zusammenführungen festgelegt werden, bei denen alle Eltern außer dem
erste wurden bereits in SVN gepusht.

--interaktiv
Bitten Sie den Benutzer, zu bestätigen, dass ein Patch-Set tatsächlich an SVN gesendet werden soll. Für jede
Patch, kann man mit "ja" (diesen Patch akzeptieren), "nein" (diesen Patch verwerfen), "alle" antworten
(alle Patches akzeptieren) oder "beenden".

git svn dcommit kehrt sofort zurück, wenn die Antwort "nein" oder "quit" ist, ohne
SVN etwas zu verpflichten.

Filiale
Erstellen Sie einen Zweig im SVN-Repository.

-m, --nachricht
Ermöglicht die Angabe der Commit-Nachricht.

-t, -tag
Erstellen Sie ein Tag, indem Sie das tags_subdir anstelle des angegebenen branchs_subdir verwenden
während git svn init.

-D , --destination=
Wenn mehr als eine Option --branches (oder --tags) an die init or klonen
Befehl müssen Sie den Speicherort des Zweigs (oder Tags) angeben, den Sie erstellen möchten
im SVN-Repository. gibt an, welcher Pfad zum Erstellen der Verzweigung verwendet werden soll oder
Tag und sollte dem Muster auf der linken Seite eines der konfigurierten
Branches oder Tags refspecs. Sie können diese Refspecs mit den Befehlen sehen

git config --get-all svn-remote. .Geäst
git config --get-all svn-remote. .Stichworte

wo ist der Name des SVN-Repositorys, wie durch die Option -R angegeben, um
init (oder "svn" standardmäßig).

--Nutzername
Geben Sie den SVN-Benutzernamen an, unter dem der Commit ausgeführt werden soll. Diese Option überschreibt die
Benutzername Konfigurationseigenschaft.

--commit-URL
Verwenden Sie die angegebene URL, um eine Verbindung zum Ziel-Subversion-Repository herzustellen. Das ist
nützlich in Fällen, in denen das Quell-SVN-Repository schreibgeschützt ist. Diese Option
überschreibt die Konfigurationseigenschaft Commiturl.

git config --get-all svn-remote. .commiturl

--Eltern
Erstellen Sie übergeordnete Ordner. Dieser Parameter entspricht dem Parameter --parents on
svn cp-Befehle und ist nützlich für nicht standardmäßige Repository-Layouts.

Etikett
Erstellen Sie ein Tag im SVN-Repository. Dies ist eine Abkürzung für Filiale -t.

Log
Dies sollte es einfach machen, svn-Protokollnachrichten nachzuschlagen, wenn svn-Benutzer darauf verweisen
-r/--Revisionsnummern.

Die folgenden Funktionen von 'svn log' werden unterstützt:

-R [: ], --revision= [: ]
wird unterstützt, nicht numerische Argumente nicht: HEAD, NEXT, BASE, PREV, etc ...

-v, --verbose
es ist nicht vollständig kompatibel mit der --verbose-Ausgabe in svn log, aber
einigermaßen nahe.

--limit=
ist NICHT dasselbe wie --max-count, zählt keine zusammengeführten/ausgeschlossenen Commits

--inkrementell
unterstützt

Neue Features:

--show-commit
zeigt auch den Git-Commit sha1 an

--eine Linie
unsere Version von --pretty=oneline

Hinweis
SVN selbst speichert nur Zeiten in UTC und sonst nichts. Der reguläre svn-Client
konvertiert die UTC-Zeit in die lokale Zeit (oder basierend auf der TZ=-Umgebung). Dies
Befehl hat das gleiche Verhalten.
Alle anderen Argumente werden direkt an . übergeben git Log

Schuld
Zeigen Sie an, welche Revision und welcher Autor jede Zeile einer Datei zuletzt geändert hat. Die Ausgabe davon
mode ist standardmäßig formatkompatibel mit der Ausgabe von 'svn tadeln'. Wie der SVN
Befehl tadeln, lokale nicht festgeschriebene Änderungen im Arbeitsbaum werden ignoriert; die Version
der Datei in der HEAD-Revision ist annotiert. Unbekannte Argumente werden direkt übergeben
zu git Schuld.

--git-format
Produzieren Sie die Ausgabe im gleichen Format wie git Schuld, aber mit SVN-Revisionsnummern
statt Git-Commit-Hashes. In diesem Modus Änderungen, die nicht festgeschrieben wurden
SVN (einschließlich lokaler Arbeitskopie-Bearbeitungen) werden als Revision 0 angezeigt.

find-rev
Bei Angabe einer SVN-Revisionsnummer des Formulars rN, gibt den entsprechenden Git-Commit zurück
Hash (dies kann optional von einem Tree-ish gefolgt werden, um anzugeben, welcher Zweig sein soll
gesucht). Gibt bei Angabe eines Baums die entsprechende SVN-Revisionsnummer zurück.

-B, --vorher
Erfordert keine genaue Übereinstimmung, wenn eine SVN-Revision angegeben wird, sondern suchen Sie nach dem Commit
entsprechend dem Stand des SVN-Repositorys (im aktuellen Zweig) am
angegebene Überarbeitung.

-A, --nach
Keine genaue Übereinstimmung erforderlich, wenn eine SVN-Revision angegeben wird; wenn es keine genaue gibt
match gibt die nächste Übereinstimmung zurück, die im Verlauf vorwärts sucht.

Set-Baum
Sie sollten erwägen, zu verwenden dcommit anstelle dieses Befehls. Commit angegebenen Commit oder
Baumobjekte zu SVN. Dies setzt voraus, dass Ihre importierten Abrufdaten aktuell sind. Dies
unternimmt absolut keine Versuche, Patches durchzuführen, wenn Sie sich auf SVN begeben, es ist einfach
überschreibt Dateien mit denen, die im Baum oder Commit angegeben sind. Es wird davon ausgegangen, dass alle Zusammenführungen
unabhängig davon stattgefunden haben git svn Funktionen.

erstellen-ignorieren
Findet rekursiv die Eigenschaft svn:ignore in Verzeichnissen und erstellt passende
.gitignore-Dateien. Die resultierenden Dateien werden bereitgestellt, um festgeschrieben zu werden, sind dies jedoch nicht
engagiert sein. Verwenden Sie -r/--revision, um auf eine bestimmte Revision zu verweisen.

anzeigen-ignorieren
Sucht rekursiv die Eigenschaft svn:ignore in Verzeichnissen und listet sie auf. Die Ausgabe ist
geeignet zum Anhängen an die Datei $GIT_DIR/info/exclude.

mkdirs
Versuche, leere Verzeichnisse neu zu erstellen, die Core-Git basierend auf Informationen nicht verfolgen kann
in $GIT_DIR/svn/ /unhandled.log-Dateien. Leere Verzeichnisse werden automatisch
wird neu erstellt, wenn "git svn clone" und "git svn rebase" verwendet werden, also ist "mkdirs" für
Verwenden Sie nach Befehlen wie "git checkout" oder "git reset". (Siehe die
svn-Fernbedienung. .automkdirs-Konfigurationsdateioption für weitere Informationen.)

Commit-Diff
Übergibt den Diff von zwei baumartigen Argumenten von der Befehlszeile. Dieser Befehl funktioniert
verlassen sich nicht darauf, sich in einem git svn init-ed Repository zu befinden. Dieser Befehl dauert drei
Argumente, (a) der ursprüngliche Baum, gegen den abgegrenzt werden soll, (b) das neue Baumergebnis, (c) die URL
des Ziel-Subversion-Repositorys. Das letzte Argument (URL) kann weggelassen werden, wenn Sie
arbeiten von a git svn-bewusstes Repository (das mit initiert wurde) git svn). Die
-R Dazu ist eine Option erforderlich.

Info
Zeigt Informationen zu einer Datei oder einem Verzeichnis an, ähnlich wie bei 'svn info'. Tut
unterstützt derzeit kein -r/--revision-Argument. Verwenden Sie die Option --url nur für die Ausgabe
der Wert der URL: Feld.

proplist
Listet die im Subversion-Repository gespeicherten Eigenschaften zu einer bestimmten Datei auf oder
Verzeichnis. Verwenden Sie -r/--revision, um auf eine bestimmte Subversion-Revision zu verweisen.

Propget
Ruft die als erstes Argument angegebene Subversion-Eigenschaft für eine Datei ab. Eine spezifische
Revision kann mit -r/--revision angegeben werden.

Show-Externals
Zeigt die Subversion-Externen an. Verwenden Sie -r/--revision, um eine bestimmte Revision anzugeben.

gc
Komprimieren von $GIT_DIR/svn/ /unhandled.log-Dateien und entfernen
$GIT_DIR/svn/ /index-Dateien.

zurückstellen
Macht die Auswirkungen von rückgängig holen zurück zur angegebenen Revision. Damit kannst du
Re-holen eine SVN-Revision. Normalerweise sollte sich der Inhalt einer SVN-Revision nie ändern
und zurückstellen sollte nicht nötig sein. Wenn sich jedoch die SVN-Berechtigungen ändern oder Sie ändern
Ihre --ignore-paths Option, a holen kann mit "nicht in Commit gefunden" fehlschlagen (Datei nicht
zuvor sichtbar) oder "Prüfsummenübereinstimmung" (eine Änderung verpasst). Wenn das Problem
Datei kann nicht für immer ignoriert werden (mit --ignore-paths) die einzige Möglichkeit, das Repository zu reparieren
ist die Verwendung von zurückstellen.

Nur die rev_map und refs/remotes/git-svn werden geändert (siehe $GIT_DIR/svn/**/.rev_map.*
im Abschnitt DATEIEN unten für Details). Folgen zurückstellen mit einem holen und dann git zurückstellen
or git zurückweisen um lokale Zweige in den neuen Baum zu verschieben.

-R , --revision=
Geben Sie die neueste Version an, die beibehalten werden soll. Alle späteren Revisionen werden verworfen.

-p, --übergeordnet
Verwerfen Sie auch die angegebene Revision und behalten Sie stattdessen das nächste übergeordnete Element bei.

Ejemplo:
Angenommen, Sie haben lokale Änderungen in "master", aber Sie müssen "r2" erneut abrufen.

r1---r2---r3 Fernbedienungen/git-svn

A---B-Meister

Beheben Sie das Problem mit Ignore-Paths oder SVN-Berechtigungen, das dazu führte, dass "r2" unvollständig war
an erster Stelle. Dann:

git svn reset -r2 -p
git svn holen

r1---r2'--r3' Fernbedienungen/git-svn

r2---r3---A---B-Master

Dann fixiere "Master" mit git zurückweisen. Verwende nicht git fusionieren oder deine Geschichte wird nicht
zukunftsfähig sein dcommit!

git rebase --onto remotes/git-svn A^ Master

r1---r2'--r3' Fernbedienungen/git-svn

A'--B' Meister

OPTIONAL

--shared[=(false|true|umask|group|all|world|everybody)], --template=
Nur verwendet mit dem init Befehl. Diese werden direkt weitergegeben an git init.

-R , --Revision
Verwendet mit dem holen Befehl.

Dies ermöglicht die Unterstützung von Revisionsbereichen für die partielle/kauterisierte Historie. $NUMMER,
$NUMBER1:$NUMBER2 (numerische Bereiche), $NUMBER:HEAD und BASE:$NUMBER werden alle unterstützt.

Auf diese Weise können Sie beim Ausführen von fetch teilweise Spiegelungen erstellen. ist aber im Allgemeinen nicht
empfohlen, da der Verlauf übersprungen wird und verloren geht.

-, --stdin
Nur verwendet mit dem Set-Baum Befehl.

Lesen Sie eine Liste von Commits von stdin und übertragen Sie sie in umgekehrter Reihenfolge. Nur die führenden
sha1 wird aus jeder Zeile gelesen, also git Drehzahlliste --pretty=einzeilig Ausgang verwendet werden kann.

--rmdir
Nur verwendet mit dem dcommit, Set-Baum und Commit-Diff Befehle.

Entfernen Sie Verzeichnisse aus dem SVN-Baum, wenn keine Dateien zurückbleiben. SVN kann
Version leere Verzeichnisse, und sie werden nicht standardmäßig entfernt, wenn keine Dateien vorhanden sind
in ihnen gelassen. Git kann leere Verzeichnisse nicht versionieren. Wenn Sie dieses Flag aktivieren, wird das
Commit to SVN handeln wie Git.

Konfigurationsschlüssel: svn.rmdir

-e, --edit
Nur verwendet mit dem dcommit, Set-Baum und Commit-Diff Befehle.

Bearbeiten Sie die Commit-Nachricht, bevor Sie ein Commit zu SVN durchführen. Dies ist standardmäßig für Objekte deaktiviert
das sind Commits, die beim Commit von Baumobjekten erzwungen werden.

Konfigurationsschlüssel: svn.edit

-l , --Kopien-finden-härter
Nur verwendet mit dem dcommit, Set-Baum und Commit-Diff Befehle.

Sie werden beide direkt weitergegeben an git Diff-Baum; sehen Git-Diff-Baum(1) für mehr
Informationen.

Konfigurationsschlüssel: svn.l
Konfigurationsschlüssel: svn.findcopiesharder

-EIN , --authors-file=
Syntax ist mit der Datei kompatibel, die von verwendet wird git cvsimport:

Loginname = Joe Useruser@example.com>

Wenn diese Option angegeben ist und git svn trifft auf einen SVN-Committer-Namen, der nicht
in der Autorendatei vorhanden, git svn bricht den Betrieb ab. Der Benutzer muss dann
fügen Sie den entsprechenden Eintrag hinzu. Vorheriges erneut ausführen git svn Befehl nach dem
authors-Datei geändert wird, sollte der Betrieb fortgesetzt werden.

Konfigurationsschlüssel: svn.authorsfile

--authors-prog=
Wenn diese Option angegeben ist, wird für jeden SVN-Committer-Namen, der nicht im
authors-Datei, wird die angegebene Datei mit dem Committer-Namen als erster ausgeführt
Streit. Es wird erwartet, dass das Programm eine einzelne Zeile der Form "Name . zurückgibt ",
die so behandelt werden, als ob sie in der Autorendatei enthalten wären.

-q, --leise
Marke git svn weniger ausführlich. Geben Sie ein zweites Mal an, um es noch weniger ausführlich zu machen.

-m, --merge, -s , --strategie= , -p, --preserve-merges
Diese werden nur mit dem verwendet dcommit und zurückweisen Befehle.

Direkt weitergegeben an git zurückweisen bei der Verwendung von dcommit wenn eine git zurückstellen nicht verwendbar (siehe
dcommit).

-n, --Trockenlauf
Dies kann mit dem verwendet werden dcommit, zurückweisen, Filiale und Etikett Befehle.

Für dcommit, drucke die Reihe von Git-Argumenten aus, die zeigen würden, welche Diffs würden
SVN verpflichtet sein.

Für zurückweisen, zeigen Sie den lokalen Zweig an, der mit dem Upstream-SVN-Repository verknüpft ist
mit dem aktuellen Branch und der URL des svn-Repositorys verknüpft, das abgerufen wird
von.

Für Filiale und Etikett, zeigen Sie die URLs an, die beim Erstellen der . zum Kopieren verwendet werden
Zweig oder Tag.

--use-log-author
Beim Abrufen von svn-Commits in Git (als Teil von holen, zurückweisen oder dcommit
Operationen), suchen Sie nach der ersten Von: oder Signed-off-by: Zeile in der Log-Meldung und
Verwenden Sie das als Autorenzeichenfolge.

--add-author-from
Wenn Sie sich von Git zu svn verpflichten (als Teil von Commit-Diff, Set-Baum or dcommit
Operationen), wenn die vorhandene Protokollnachricht noch kein Von enthält: oder
Signed-off-by: line, fügen Sie eine From:-Zeile basierend auf der Autorenzeichenfolge des Git-Commits an. Wenn
Wenn Sie dies verwenden, wird --use-log-author einen gültigen Autorenstring für alle abrufen
verpflichtet.

Fortgeschritten OPTIONAL

-ich , --Ich würde
Dies setzt GIT_SVN_ID (anstatt die Umgebung zu verwenden). Dies ermöglicht dem Benutzer,
Überschreiben Sie den Standard-Refname, von dem abgerufen werden soll, wenn eine einzelne URL verfolgt wird. Der Log und
dcommit Befehle benötigen diesen Schalter nicht mehr als Argument.

-R , --svn-remote
Geben Sie die [svn-remote " "] Abschnitt zu verwenden, dies ermöglicht mehrere SVN
Repositorys zu verfolgen. Standard: "svn"

--folge-eltern
Diese Option ist nur relevant, wenn wir Branches verfolgen (mit einem der Repositorys
Layoutoptionen --trunk, --tags, --branches, --stdlayout). Versuchen Sie es für jeden verfolgten Zweig
um herauszufinden, woher die Revision kopiert wurde, und legen Sie im ersten ein geeignetes übergeordnetes Element fest
Git-Commit für den Branch. Dies ist besonders hilfreich, wenn wir ein Verzeichnis verfolgen
die innerhalb des Repositorys verschoben wurde. Wenn diese Funktion deaktiviert ist, wird die
Filialen erstellt von git svn werden alle linear sein und keine Geschichte teilen, was bedeutet, dass
es werden keine Informationen darüber gegeben, wo Filialen abgezweigt oder zusammengelegt wurden. Jedoch,
Das Verfolgen langer/verschachtelter Historien kann lange dauern, daher deaktivieren Sie diese Funktion
kann den Klonvorgang beschleunigen. Diese Funktion ist standardmäßig aktiviert, verwenden Sie
--no-follow-parent, um es zu deaktivieren.

Konfigurationsschlüssel: svn.followparent

CONFIG NUR DATEI OPTIONAL

svn.noMetadata, svn-remote. .noMetadaten
Dies wird die los git-svn-id: Zeilen am Ende jedes Commits.

Diese Option kann nur für One-Shot-Importe verwendet werden, da git svn kann nicht holen
wieder ohne Metadaten. Außerdem, wenn Sie Ihr verlieren $GIT_DIR/svn/**/.rev_map.*
Dateien, git svn wird sie nicht wieder aufbauen können.

Die git svn Log Der Befehl funktioniert auch nicht bei Repositorys, die dies verwenden. Verwenden Sie dies
Konflikte mit den Verwenden Sie SvmProps Option aus (hoffentlich) offensichtlichen Gründen.

Diese Option wird NICHT empfohlen, da es das Auffinden alter Referenzen erschwert
zu SVN-Revisionsnummern in bestehenden Dokumentationen, Fehlerberichten und Archiven. wenn du
planen, irgendwann von SVN zu Git zu migrieren und sind sich sicher, den SVN-Verlauf zu löschen,
Erwägen git-filter-Zweig(1) statt. Filter-Zweig ermöglicht auch die Neuformatierung von
Metadaten zum leichteren Lesen und Umschreiben von Autoreninformationen für Nicht-"svn.authorsFile"
Benutzer.

svn.useSvmProps, svn-remote. .useSvmProps
Dies erlaubt git svn um Repository-URLs und UUIDs von Spiegeln neu zuzuordnen, die mit erstellt wurden
SVN::Mirror (oder svk) für Metadaten.

Wenn eine SVN-Revision die Eigenschaft "svm:headrev" hat, war die Revision wahrscheinlich
erstellt von SVN::Mirror (wird auch von SVK verwendet). Die Eigenschaft enthält eine Repository-UUID und
eine Überarbeitung. Wir möchten, dass es so aussieht, als ob wir die ursprüngliche URL spiegeln, also
eine Hilfsfunktion einführen, die die ursprüngliche Identitäts-URL und UUID zurückgibt, und verwenden
es beim Generieren von Metadaten in Commit-Nachrichten.

svn.useSvnsyncProps, svn-remote. .useSvnsyncprops
Ähnlich der useSvmProps-Option; Dies ist für Benutzer der svnsync(1) Befehl
verteilt mit SVN 1.4.x und höher.

svn-Fernbedienung. .rewriteRoot
Auf diese Weise können Benutzer Repositorys aus alternativen URLs erstellen. Zum Beispiel ein
Administrator könnte laufen git svn auf dem Server lokal (Zugriff über file://) aber wünschen
um das Repository mit einer öffentlichen http:// oder svn:// URL in den Metadaten zu verteilen so
Benutzer davon sehen die öffentliche URL.

svn-Fernbedienung. .rewriteUUID
Ähnlich der useSvmProps-Option; Dies ist für Benutzer, die die UUID neu zuordnen müssen
manuell. Dies kann in Situationen nützlich sein, in denen die ursprüngliche UUID nicht verfügbar ist
entweder über useSvmProps oder useSvnsyncProps.

svn-Fernbedienung. .pushurl
Ähnlich wie Gits Fernbedienung. .pushurl, dieser Schlüssel ist für Fälle vorgesehen, in denen
URL verweist über einen schreibgeschützten Transport auf ein SVN-Repository, um eine Alternative bereitzustellen
Lese-/Schreibtransport. Es wird davon ausgegangen, dass beide Schlüssel auf dasselbe Repository verweisen.
Im Gegensatz zu Commiturl, pushurl ist ein Basispfad. Wenn entweder Commiturl or pushurl könnte sein
benutzt, Commiturl hat Vorrang.

svn.brokenSymlinkWorkaround
Dadurch werden potenziell kostspielige Überprüfungen deaktiviert, um defekte symbolische Links zu umgehen, die eingecheckt wurden
SVN von defekten Clients. Setzen Sie diese Option auf "false", wenn Sie ein SVN-Repository mit verfolgen
viele leere Blobs, die keine symbolischen Links sind. Diese Option kann geändert werden, während git svn is
ausgeführt und bei der nächsten abgerufenen Revision wirksam. Wenn nicht eingestellt, git svn geht davon aus
Option "wahr" sein.

svn.pathnameencoding
Dies weist git svn an, Pfadnamen in eine bestimmte Kodierung umzukodieren. Es kann verwendet werden von
Windows-Benutzer und von denen, die in Nicht-utf8-Locales arbeiten, um beschädigte Dateinamen zu vermeiden
mit Nicht-ASCII-Zeichen. Gültige Codierungen werden von Perls Encode unterstützt
Modul.

svn-Fernbedienung. .automkdirs
Normalerweise versuchen die Befehle "git svn clone" und "git svn rebase", leere Dateien wiederherzustellen
Verzeichnisse, die sich im Subversion-Repository befinden. Wenn diese Option auf "false" gesetzt ist,
dann werden leere Verzeichnisse nur erstellt, wenn der Befehl "git svn mkdirs" ausgeführt wird
ausdrücklich. Wenn nicht eingestellt, git svn geht davon aus, dass diese Option "wahr" ist.

Da die Optionen noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps und useSvmProps
alle wirken sich auf die Metadaten aus, die von . generiert und verwendet werden git svn; sie sollen in der eingestellt werden
Konfigurationsdatei, bevor ein Verlauf importiert wird, und diese Einstellungen sollten niemals
geändert, sobald sie eingestellt sind.

Außerdem kann nur eine dieser Optionen pro svn-remote-Abschnitt verwendet werden, da sie
Auswirkungen auf die git-svn-id: Metadatenzeile, außer für rewriteRoot und rewriteUUID, die sein können
zusammen verwendet.

BASIC Beispiele:

Verfolgen und Beitragen zum Stamm eines von Subversion verwalteten Projekts (Ignorieren von Tags und
Geäst):

# Klonen Sie ein Repo (wie git clone):
git svn klonen http://svn.example.com/project/trunk
# Geben Sie das neu geklonte Verzeichnis ein:
CD-Trunk
# Sie sollten sich im Master-Branch befinden, überprüfen Sie es mit 'git branch'
Git Zweig
# Machen Sie etwas Arbeit und übertragen Sie lokal Git:
git-commit...
# Etwas ist an SVN gebunden. Basieren Sie Ihre lokalen Änderungen gegen die
# letzte Änderungen im SVN:
Git SVN Rebase
# Übertragen Sie nun Ihre Änderungen (die zuvor mit Git festgeschrieben wurden) an SVN,
# sowie die automatische Aktualisierung Ihres Arbeits-HEADs:
git svn dcommit
# Hängen Sie svn:ignore-Einstellungen an die standardmäßige Git-Ausschlussdatei an:
git svn show-ignore >> .git/info/exclude

Verfolgen und Beitragen zu einem gesamten von Subversion verwalteten Projekt (komplett mit einem Trunk,
Tags und Zweige):

# Klonen Sie ein Repo mit dem Standard-SVN-Verzeichnis-Layout (wie git clone):
git svn klonen http://svn.example.com/project --stdlayout --prefix svn/
# Oder, wenn das Repository ein nicht standardmäßiges Verzeichnislayout verwendet:
git svn klonen http://svn.example.com/project -T tr -b Zweig -t Tag --prefix svn/
# Sehen Sie sich alle Branches und Tags an, die Sie geklont haben:
Git Branch -r
# Erstelle eine neue Filiale in SVN
git svn branch waldo
# Setzen Sie Ihren Master auf Trunk (oder einen anderen Zweig) zurück und ersetzen Sie 'trunk'
# mit dem entsprechenden Namen):
git reset --hard svn/trunk
# Sie können sich jeweils nur auf einen Branch/Tag/Trunk dcommitieren. Die Verwendung
# von dcommit/rebase/show-ignore sollte die gleiche wie oben sein.

Die anfängliche git svn klonen kann ziemlich zeitaufwändig sein (insbesondere für große Subversion
Depots). Wenn mehrere Personen (oder eine Person mit mehreren Maschinen) verwenden möchten git
svn Um mit demselben Subversion-Repository zu interagieren, können Sie die erste git svn klonen
in ein Repository auf einem Server und lassen Sie jede Person dieses Repository mit klonen git klonen:

# Führen Sie den anfänglichen Import auf einem Server durch
SSH-Server "cd /pub && git svn clone http://svn.example.com/project [Optionen...]"
# Lokal klonen – stellen Sie sicher, dass die Refs/Remotes/Space mit dem Server übereinstimmen
mkdir-Projekt
CD-Projekt
git init
git remote Ursprungsserver hinzufügen:/pub/project
git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
Git holen
# Verhindern Sie in Zukunft das Abrufen / Ziehen von entfernten Git-Servern,
# wir wollen git svn nur für zukünftige Updates verwenden
git config --remove-section remote.origin
# Erstelle einen lokalen Zweig aus einem der gerade geholten Zweige
git checkout -b master FETCH_HEAD
# Initialisieren Sie 'git svn' lokal (stellen Sie sicher, dass Sie dieselbe URL verwenden und
# --stdlayout/-T/-b/-t/--prefix-Optionen, wie sie auf dem Server verwendet wurden)
git svn init http://svn.example.com/project [Optionen...]
# Ziehe die neuesten Änderungen von Subversion
Git SVN Rebase

REBASIS VS. ZIEHEN/ZIEHEN

Lieber verwenden git svn zurückweisen or git zurückweisen, Anstatt git ziehen or git fusionieren zu
nicht integrierte Commits mit a . synchronisieren git svn Ast. Dadurch wird die Geschichte von
unintegrierte Commits linear in Bezug auf das vorgelagerte SVN-Repository und erlauben die Verwendung
der bevorzugten git svn dcommit Unterbefehl, um nicht integrierte Commits zurück in SVN zu schieben.

Ursprünglich git svn empfohlen, dass Entwickler aus dem gezogenen oder zusammengeführten git svn Ast.
Dies lag daran, dass der Autor git svn set-tree B bevorzugt hat, um einen einzelnen Head zu übergeben, anstatt
die git svn set-tree A..B-Notation, um mehrere Commits zu begehen. Gebrauch von git ziehen or git
fusionieren mit git svn set-tree A..B bewirkt, dass der nichtlineare Verlauf abgeflacht wird, wenn
Commit in SVN und dies kann dazu führen, dass Merge-Commits unerwartet rückgängig gemacht werden
Commits im SVN.

MERGE TRACKING

Während git svn kann den Kopierverlauf (einschließlich Branches und Tags) für Repositorys verfolgen
Wenn Sie ein Standard-Layout übernehmen, kann es noch keinen Merge-Verlauf darstellen, der in git . passiert ist
zurück Upstream zu SVN-Benutzern. Daher wird empfohlen, dass Benutzer den Verlauf so linear wie
innerhalb von Git möglich, um die Kompatibilität mit SVN zu erleichtern (siehe den Abschnitt VORSICHTEN unten).

HANDHABUNG OF SVN BRANCHEN

If git svn konfiguriert ist, um Branches zu holen (und --follow-branches ist in Kraft), es
erstellt manchmal mehrere Git-Zweigs für einen SVN-Zweig, wobei die zusätzlichen Zweige
haben Namen der Form Filialname@nnn (mit nnn eine SVN-Revisionsnummer). Diese zusätzlichen
Zweige werden erstellt, wenn git svn kann keinen übergeordneten Commit für den ersten Commit in einem SVN finden
branch, um den Zweig mit der Historie der anderen Zweige zu verbinden.

Normalerweise besteht der erste Commit in einem SVN-Zweig aus einem Kopiervorgang. git svn werden wir
Lesen Sie diesen Commit, um die SVN-Revision zu erhalten, aus der der Zweig erstellt wurde. Es wird dann versuchen
Suchen Sie das Git-Commit, das dieser SVN-Revision entspricht, und verwenden Sie es als übergeordnetes Element von
die Branche. Es ist jedoch möglich, dass es kein geeignetes Git-Commit gibt, als das er dienen kann
Elternteil. Dies geschieht unter anderem, wenn der SVN-Zweig eine Kopie einer Revision ist
das wurde nicht geholt von git svn (zB weil es sich um eine alte Revision handelt, die mit übersprungen wurde
--Revision), oder wenn in SVN ein Verzeichnis kopiert wurde, das nicht von git svn (so wie ein
Zweig, der überhaupt nicht verfolgt wird, oder ein Unterverzeichnis eines verfolgten Zweigs). In diesen Fällen,
git svn wird immer noch einen Git-Zweig erstellen, aber anstatt einen vorhandenen Git-Commit als
übergeordnetes Element des Zweigs, es wird die SVN-Historie des Verzeichnisses gelesen, in das der Zweig kopiert wurde
from und erstellen Sie entsprechende Git-Commits. Dies wird durch die Meldung „Initializing
Elternteil: ".

Darüber hinaus wird ein spezieller Zweig namens . erstellt @, Wobei
ist die SVN-Revisionsnummer, von der der Zweig kopiert wurde. Diese Filiale wird
zeigen Sie auf den neu erstellten übergeordneten Commit des Zweigs. Wenn im SVN die Filiale gelöscht wurde
und später aus einer anderen Version neu erstellt, gibt es mehrere solcher Zweige mit einem
@.

Beachten Sie, dass dies bedeuten kann, dass mehrere Git-Commits für eine einzelne SVN-Revision erstellt werden.

Ein Beispiel: in einem SVN-Repository mit einem Standard-Trunk/Tags/Zweig-Layout ein Verzeichnis
Trunk/Sub wird in r.100 erstellt. In r.200 wird trunk/sub verzweigt, indem man es nach Branches/ kopiert.
git svn klonen -s wird dann eine Filiale erstellen unten. Es erstellt auch neue Git-Commits für
r.100 bis r.199 und verwenden Sie diese als Geschichte der Branche unten. Somit wird es zwei Git . geben
Commits für jede Revision von r.100 bis r.199 (eine mit Trunk/, eine mit
Stamm/Sub/). Schließlich wird ein Zweig erstellt sub@200 zeigt auf das neue Eltern-Commit von
Filiale unten (zB der Commit für r.200 und trunk/sub/).

VORSICHTEN

Der Einfachheit halber und der Interoperabilität mit Subversion wird empfohlen, dass alle
git svn Benutzer klonen, holen und dcommit direkt vom SVN-Server und vermeiden alles git
klonen/ziehen/fusionieren/drücken Operationen zwischen Git-Repositorys und Branches. Das Empfohlene
Methode zum Austausch von Code zwischen Git-Branchen und Benutzern ist git Format-Patch und git am,
oder einfach an das SVN-Repository 'dcommit'.

Laufen git fusionieren or git ziehen wird NICHT für eine Filiale empfohlen, die Sie planen dcommit von
weil Subversion-Benutzer keine von Ihnen vorgenommenen Zusammenführungen sehen können. Außerdem, wenn Sie zusammenführen oder
aus einem Git-Zweig ziehen, der ein Spiegel eines SVN-Zweigs ist, dcommit kann sich zum falschen begehen
Ast.

Beachten Sie beim Zusammenführen die folgende Regel: git svn dcommit wird versuchen, sich zusätzlich zu verpflichten
der SVN-Commit namens in

git log --grep=^git-svn-id: --first-parent -1

Dir sollen Stellen Sie daher sicher, dass das neueste Commit des Branchs, für den Sie ein dcommit durchführen möchten
ist das zuerst übergeordnetes Element der Zusammenführung. Andernfalls kommt es zu Chaos, besonders wenn der erste
parent ist ein älterer Commit im selben SVN-Zweig.

git klonen klont keine Branches unter der refs/remotes/hierarchie oder anderen git svn
Metadaten oder config. Also Repositorys erstellt und verwaltet mit using git svn sollte verwenden
rsync zum Klonen, wenn überhaupt geklont werden soll.

Da dcommit verwendet Rebase intern, alle Git-Zweigstellen Sie git drücken zu vorher dcommit on
erfordert das Überschreiben der vorhandenen Referenz im Remote-Repository. Das ist
allgemein als schlechte Praxis angesehen, siehe die Git-Push(1) Dokumentation für Details.

Verwenden Sie nicht die Option --amend von Git-Commit(1) bei einer Änderung, die Sie bereits freigegeben haben. Es
wird als schlechte Methode angesehen, Commits zu ändern, die Sie bereits in ein Remote-Repository verschoben haben
für andere Benutzer, und dcommit mit SVN ist analog dazu.

Beim Klonen eines SVN-Repositorys, wenn keine der Optionen zum Beschreiben des Repositorys
Layout verwendet wird (--trunk, --tags, --branches, --stdlayout), git svn klonen wird ein Git . erstellen
Repository mit vollständig linearem Verlauf, in dem Branches und Tags separat erscheinen
Verzeichnisse in der Arbeitskopie. Dies ist zwar der einfachste Weg, um eine Kopie einer vollständigen
Repository, bei Projekten mit vielen Branches führt es oft zu einer Arbeitskopie
größer als nur der Kofferraum. Also für Projekte, die die Standard-Verzeichnisstruktur verwenden
(Trunk/Branches/Tags), es wird empfohlen, mit Option zu klonen --stdlayout. Wenn das Projekt
verwendet eine nicht standardmäßige Struktur, und/oder wenn Verzweigungen und Tags nicht erforderlich sind, ist es am einfachsten
nur ein Verzeichnis (normalerweise Trunk) zu klonen, ohne ein Repository-Layout anzugeben
Optionen. Wenn der vollständige Verlauf mit Verzweigungen und Tags benötigt wird, sind die Optionen --Stamm /
--Geäst / --Stichworte muss benutzt werden.

Wenn Sie mehrere --branches oder --tags verwenden, git svn verarbeitet Namen nicht automatisch
Kollisionen (zum Beispiel wenn zwei Zweige von unterschiedlichen Pfaden den gleichen Namen haben oder wenn a
Zweig und ein Tag haben denselben Namen). Verwenden Sie in diesen Fällen init um dein Git . einzurichten
Repository dann vor deinem ersten holen, bearbeiten Sie die Datei $GIT_DIR/config so, dass die
Branches und Tags sind mit unterschiedlichen Namensräumen verknüpft. Beispielsweise:

Branches = stable/*:refs/remotes/svn/stable/*
branchen = debug/*:refs/remotes/svn/debug/*

Verwenden Sie git-svn online mit den onworks.net-Diensten