English ▾ Themen ▾ Neueste Version ▾ git-svn zuletzt aktualisiert in 2.52.0

NAME

git-svn - Bidirektionale Operation zwischen einem Subversion-Repository und Git

SYNOPSIS

git svn <command> [<options>] [<arguments>]

BESCHREIBUNG

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

git svn kann ein Standard-Subversion-Repository verfolgen, das dem üblichen Layout "trunk/branches/tags" folgt, mit der Option --stdlayout. Es kann auch Branches und Tags in jedem Layout mit den Optionen -T/-t/-b verfolgen (siehe Optionen für init unten und auch den Befehl clone).

Sobald ein Subversion-Repository verfolgt wird (mit einer der oben genannten Methoden), kann das Git-Repository mit dem Befehl fetch aus Subversion aktualisiert werden und Subversion mit dem Befehl dcommit aus Git aktualisiert werden.

BEFEHLE

init

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

-T<trunk-subdir>
--trunk=<trunk-subdir>
-t<tags-subdir>
--tags=<tags-subdir>
-b<branches-subdir>
--branches=<branches-subdir>
-s
--stdlayout

Dies sind optionale Kommandozeilenoptionen für init. Jede dieser Flags kann auf einen relativen Repository-Pfad (--tags=projekt/tags) oder eine vollständige URL (--tags=https://foo.org/project/tags) verweisen. Sie können mehr als eine --tags und/oder --branches Option angeben, falls Ihr Subversion-Repository Tags oder Branches unter mehreren Pfaden platziert. Die Option --stdlayout ist eine Abkürzung für die Einstellung von trunk,tags,branches als relative Pfade, was der Subversion-Standard ist. Wenn eine der anderen Optionen ebenfalls angegeben wird, haben diese Vorrang.

--no-metadata

Setzt die Option noMetadata in der [svn-remote] Konfiguration. Diese Option wird nicht empfohlen. Lesen Sie den Abschnitt svn.noMetadata dieser Manpage, bevor Sie diese Option verwenden.

--use-svm-props

Setzt die Option useSvmProps in der [svn-remote] Konfiguration.

--use-svnsync-props

Setzt die Option useSvnsyncProps in der [svn-remote] Konfiguration.

--rewrite-root=<URL>

Setzt die Option rewriteRoot in der [svn-remote] Konfiguration.

--rewrite-uuid=<UUID>

Setzt die Option rewriteUUID in der [svn-remote] Konfiguration.

--username=<user>

Für Transporte, für die SVN die Authentifizierung übernimmt (http, https und plain svn), geben Sie den Benutzernamen an. Für andere Transporte (z. B. svn+ssh://) müssen Sie den Benutzernamen in die URL aufnehmen, z. B. svn+ssh://foo@svn.bar.com/project

--prefix=<prefix>

Dies erlaubt die Angabe eines Präfixes, das den Namen von Remotes vorangestellt wird, wenn trunk/branches/tags angegeben sind. Das Präfix enthält nicht automatisch einen abschließenden Schrägstrich, stellen Sie also sicher, dass Sie einen in das Argument einfügen, wenn Sie das wünschen. Wenn --branches/-b angegeben wird, muss das Präfix einen abschließenden Schrägstrich enthalten. In jedem Fall wird die Einstellung eines Präfixes (mit einem abschließenden Schrägstrich) dringend empfohlen, da Ihre SVN-verfolgten Refs dann unter "refs/remotes/$prefix/**" liegen, was mit dem eigenen Remote-Tracking-Ref-Layout von Git (refs/remotes/$remote/**) kompatibel ist. Die Einstellung eines Präfixes ist auch nützlich, wenn Sie mehrere Projekte verfolgen möchten, die sich ein gemeinsames Repository teilen. Standardmäßig ist das Präfix auf origin/ gesetzt.

Hinweis
 Vor Git v2.0 war das Standardpräfix "" (kein Präfix). Das bedeutete, dass SVN-verfolgte Refs unter "refs/remotes/*" abgelegt wurden, was nicht mit der Organisation von Git's eigenen Remote-Tracking-Refs kompatibel ist. Wenn Sie immer noch den alten Standard wünschen, können Sie ihn erhalten, indem Sie --prefix "" auf der Kommandozeile übergeben (--prefix="" funktioniert möglicherweise nicht, wenn Ihr Perl's Getopt::Long < v2.37 ist).
--ignore-refs=<regex>

Wenn dies an init oder clone übergeben wird, wird dieses reguläre Ausdrucksmuster als Konfigurationsschlüssel gespeichert. Siehe fetch für eine Beschreibung von --ignore-refs.

--ignore-paths=<regex>

Wenn dies an init oder clone übergeben wird, wird dieses reguläre Ausdrucksmuster als Konfigurationsschlüssel gespeichert. Siehe fetch für eine Beschreibung von --ignore-paths.

--include-paths=<regex>

Wenn dies an init oder clone übergeben wird, wird dieses reguläre Ausdrucksmuster als Konfigurationsschlüssel gespeichert. Siehe fetch für eine Beschreibung von --include-paths.

--no-minimize-url

Beim Verfolgen mehrerer Verzeichnisse (mithilfe der Optionen --stdlayout, --branches oder --tags) versucht git svn, eine Verbindung zum Stammverzeichnis (oder zur höchstmöglichen Ebene) des Subversion-Repositorys herzustellen. Dieser Standard ermöglicht eine bessere Verfolgung der Historie, wenn ganze Projekte innerhalb eines Repositorys verschoben werden, kann aber Probleme bei Repositorys mit Lesezugriffsbeschränkungen verursachen. Die Übergabe von --no-minimize-url ermöglicht es git svn, URLs unverändert zu akzeptieren, ohne zu versuchen, eine Verbindung zu einem Verzeichnis auf einer höheren Ebene herzustellen. Diese Option ist standardmäßig deaktiviert, wenn nur eine URL/ein Branch verfolgt wird (sie wäre wenig nützlich).

fetch

Holt nicht abgeholte Revisionen vom Subversion-Remote, das wir verfolgen. Der Name des [svn-remote "..."]-Abschnitts in der $GIT_DIR/config-Datei kann als optionales Kommandozeilenargument angegeben werden.

Dies aktualisiert automatisch die rev_map, falls erforderlich (siehe $GIT_DIR/svn/**/.rev_map.* im Abschnitt FILES unten für Details).

--localtime

Speichert Git-Commit-Zeiten in der lokalen Zeitzone anstelle von UTC. Dies bewirkt, dass git log (auch ohne --date=local) dieselben Zeiten anzeigt, die svn log in der lokalen Zeitzone anzeigen würde.

Dies beeinträchtigt nicht die Interoperabilität mit dem Subversion-Repository, von dem Sie geklont haben. Wenn Sie jedoch möchten, dass Ihr lokales Git-Repository mit dem lokalen Git-Repository eines anderen Benutzers interoperabel ist, verwenden Sie diese Option entweder nicht oder beide verwenden sie in derselben lokalen Zeitzone.

--parent

Holt nur vom SVN-Elternteil des aktuellen HEAD.

--ignore-refs=<regex>

Ignoriert Refs für Branches oder Tags, die dem Perl-Regulären Ausdruck entsprechen. Eine "Negative Lookahead Assertion" wie ^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$ kann verwendet werden, um nur bestimmte Refs zuzulassen.

config key: svn-remote.<name>.ignore-refs

Wenn der ignore-refs Konfigurationsschlüssel gesetzt ist und die Kommandozeilenoption ebenfalls angegeben wird, werden beide regulären Ausdrücke verwendet.

--ignore-paths=<regex>

Dies erlaubt die Angabe eines Perl-Regulären Ausdrucks, der das Überspringen aller übereinstimmenden Pfade beim Checkout aus SVN bewirkt. Die Option --ignore-paths muss für jeden fetch (einschließlich automatischer Fetches aufgrund von clone, dcommit, rebase usw.) in einem gegebenen Repository übereinstimmen.

config key: svn-remote.<name>.ignore-paths

Wenn der ignore-paths Konfigurationsschlüssel gesetzt ist und die Kommandozeilenoption ebenfalls angegeben wird, werden beide regulären Ausdrücke verwendet.

Beispiele

Überspringe "doc*" Verzeichnis für jeden Fetch
--ignore-paths="^doc"
Überspringe "branches" und "tags" von Verzeichnissen der ersten Ebene
--ignore-paths="^[^/]+/(?:branches|tags)"
--include-paths=<regex>

Dies erlaubt die Angabe eines Perl-Regulären Ausdrucks, der das Einschließen nur der übereinstimmenden Pfade beim Checkout aus SVN bewirkt. Die Option --include-paths muss für jeden fetch (einschließlich automatischer Fetches aufgrund von clone, dcommit, rebase usw.) in einem gegebenen Repository übereinstimmen. --ignore-paths hat Vorrang vor --include-paths.

config key: svn-remote.<name>.include-paths
--log-window-size=<n>

Holt <n> Log-Einträge pro Anforderung beim Scannen der Subversion-Historie. Der Standard ist 100. Für sehr große Subversion-Repositorys können größere Werte erforderlich sein, damit clone/fetch in angemessener Zeit abgeschlossen werden. Übermäßig große Werte können jedoch zu höherem Speicherverbrauch und Request-Timeouts führen.

clone

Führt init und fetch aus. Es wird automatisch ein Verzeichnis erstellt, das auf dem Basisnamen der übergebenen URL basiert; oder wenn ein zweites Argument übergeben wird; es wird ein Verzeichnis erstellt und darin gearbeitet. Es akzeptiert alle Argumente, die die Befehle init und fetch akzeptieren; mit Ausnahme von --fetch-all und --parent. Nach dem Klonen eines Repositorys kann der Befehl fetch Revisionen aktualisieren, ohne den Arbeitsbaum zu beeinträchtigen; und der Befehl rebase kann den Arbeitsbaum mit den neuesten Änderungen aktualisieren.

--preserve-empty-dirs

Erstellt eine Platzhalterdatei im lokalen Git-Repository für jedes leere Verzeichnis, das aus Subversion geholt wurde. Dazu gehören Verzeichnisse, die durch das Entfernen aller Einträge im Subversion-Repository (aber nicht des Verzeichnisses selbst) leer werden. Die Platzhalterdateien werden ebenfalls verfolgt und entfernt, wenn sie nicht mehr benötigt werden.

--placeholder-filename=<filename>

Setzt den Namen der Platzhalterdateien, die von --preserve-empty-dirs erstellt werden. Standard: ".gitignore"

rebase

Dies holt Revisionen vom SVN-Elternteil des aktuellen HEAD und rebaset die aktuelle (noch nicht bei SVN committete) Arbeit dagegen.

Dies funktioniert ähnlich wie svn update oder git pull, außer dass es eine lineare Historie mit git rebase anstelle von git merge beibehält, um das Dcommitten mit git svn zu erleichtern.

Dies akzeptiert alle Optionen, die git svn fetch und git rebase akzeptieren. --fetch-all holt jedoch nur von der aktuellen [svn-remote] und nicht von allen [svn-remote]-Definitionen.

Wie git rebase; erfordert dies, dass der Arbeitsbaum sauber ist und keine uncommitteten Änderungen aufweist.

Dies aktualisiert automatisch die rev_map, falls erforderlich (siehe $GIT_DIR/svn/**/.rev_map.* im Abschnitt FILES unten für Details).

-l
--local

Nicht remote abholen; nur git rebase gegen den zuletzt abgeholten Commit vom Upstream-SVN ausführen.

dcommit

Commit jeder Diff des aktuellen Branches direkt in das SVN-Repository und dann rebase oder reset (abhängig davon, ob eine Diff zwischen SVN und HEAD vorhanden ist). Dies erstellt eine Revision in SVN für jeden Commit in Git.

Wenn ein optionaler Git-Branch-Name (oder ein Git-Commit-Objektname) als Argument angegeben wird, arbeitet der Unterbefehl auf dem angegebenen Branch, nicht auf dem aktuellen Branch.

Die Verwendung von dcommit wird set-tree (unten) vorgezogen.

--no-rebase

Nach dem Committen nicht rebasen oder zurücksetzen.

--commit-url <URL>

Commit zu dieser SVN-URL (dem vollständigen Pfad). Dies ist dazu gedacht, die Wiederverwendung bestehender git svn-Repositorys zu ermöglichen, die mit einer Transportmethode erstellt wurden (z. B. svn:// oder http:// für anonymes Lesen), wenn ein Benutzer später Zugriff auf eine alternative Transportmethode (z. B. svn+ssh:// oder https://) für Commits erhält.

config key: svn-remote.<name>.commiturl
config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options)

Beachten Sie, dass die SVN-URL des commiturl-Konfigurationsschlüssels den SVN-Branch enthält. Wenn Sie stattdessen die Commit-URL für ein gesamtes SVN-Repository festlegen möchten, verwenden Sie stattdessen svn-remote.<name>.pushurl.

Die Verwendung dieser Option für andere Zwecke (fragen Sie nicht) wird dringend abgeraten.

--mergeinfo=<mergeinfo>

Fügt die gegebenen Merge-Informationen während des Dcommits hinzu (z. B. --mergeinfo="/branches/foo:1-10"). Alle svn-Server-Versionen können diese Informationen speichern (als Eigenschaft), und svn-Clients ab Version 1.5 können sie nutzen. Um Merge-Informationen von mehreren Branches anzugeben, verwenden Sie ein einzelnes Leerzeichen zwischen den Branches (--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8")

config key: svn.pushmergeinfo

Diese Option bewirkt, dass git-svn versucht, die svn:mergeinfo-Eigenschaft im SVN-Repository automatisch zu füllen, wenn möglich. Derzeit kann dies nur beim Dcommitten von Non-Fast-Forward-Merges geschehen, bei denen alle Eltern außer dem ersten bereits in SVN gepusht wurden.

--interactive

Fragt den Benutzer, ob ein Patch-Set tatsächlich an SVN gesendet werden soll. Für jeden Patch kann man "yes" (diesen Patch akzeptieren), "no" (diesen Patch verwerfen), "all" (alle Patches akzeptieren) oder "quit" antworten.

git svn dcommit kehrt sofort zurück, wenn die Antwort "no" oder "quit" lautet, ohne etwas an SVN zu committen.

branch

Erstellt einen Branch im SVN-Repository.

-m
--message

Ermöglicht die Angabe der Commit-Nachricht.

-t
--tag

Erstellt einen Tag unter Verwendung des tags_subdir anstelle des branches_subdir, der während git svn init angegeben wurde.

-d<path>
--destination=<path>

Wenn mehr als eine Option --branches (oder --tags) an den Befehl init oder clone übergeben wurde, müssen Sie den Speicherort des Branches (oder Tags) angeben, den Sie im SVN-Repository erstellen möchten. <path> gibt den Pfad an, der zum Erstellen des Branches oder Tags verwendet werden soll, und sollte dem Muster auf der linken Seite einer der konfigurierten Branches- oder Tags-Refspecs entsprechen. Diese Refspecs können Sie mit den folgenden Befehlen einsehen:

git config --get-all svn-remote.<name>.branches
git config --get-all svn-remote.<name>.tags

wobei <name> der Name des SVN-Repositorys ist, wie durch die Option -R für init angegeben (oder standardmäßig "svn").

--username

Gibt den SVN-Benutzernamen an, unter dem der Commit ausgeführt werden soll. Diese Option überschreibt die Konfigurationseigenschaft username.

--commit-url

Verwendet die angegebene URL, um eine Verbindung zum Ziel-Subversion-Repository herzustellen. Dies 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.<name>.commiturl
--parents

Erstellt übergeordnete Ordner. Dieser Parameter ist äquivalent zum Parameter --parents bei svn cp-Befehlen und ist nützlich für nicht standardmäßige Repository-Layouts.

tag

Erstellt einen Tag im SVN-Repository. Dies ist eine Kurzform für branch -t.

log

Dies sollte es erleichtern, svn log-Nachrichten nachzuschlagen, wenn svn-Benutzer auf -r/--revision-Nummern verweisen.

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

-r <n>[:<n>]
--revision=<n>[:<n>]

wird unterstützt, nicht-numerische Argumente nicht: HEAD, NEXT, BASE, PREV usw.

-v
--verbose

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

--limit=<n>

ist NICHT dasselbe wie --max-count, zählt keine gemergten/ausgeschlossenen Commits

--incremental

unterstützt

Neue Funktionen

--show-commit

zeigt auch den Git-Commit-Sha1 an

--oneline

unsere Version von --pretty=oneline

Hinweis
 SVN selbst speichert nur Zeiten in UTC und nichts anderes. Der reguläre svn-Client konvertiert die UTC-Zeit in die lokale Zeit (oder basierend auf der TZ=-Umgebung). Dieser Befehl verhält sich genauso.

Alle anderen Argumente werden direkt an git log übergeben

blame

Zeigt an, welche Revision und welcher Autor jede Zeile einer Datei zuletzt geändert hat. Die Ausgabe dieses Modus ist standardmäßig mit der Ausgabe von 'svn blame' kompatibel. Wie der SVN blame-Befehl werden lokale, nicht committete Änderungen im Arbeitsbaum ignoriert; die Version der Datei in der HEAD-Revision wird annotiert. Unbekannte Argumente werden direkt an git blame übergeben.

--git-format

Gibt die Ausgabe im gleichen Format wie git blame aus, aber mit SVN-Revisionsnummern anstelle von Git-Commit-Hashes. In diesem Modus werden Änderungen, die nicht in SVN committet wurden (einschließlich lokaler Arbeitskopie-Bearbeitungen), als Revision 0 angezeigt.

find-rev

Wenn eine SVN-Revisionsnummer im Format rN gegeben wird, gibt sie den entsprechenden Git-Commit-Hash zurück (dies kann optional von einem Tree-ish gefolgt werden, um anzugeben, welcher Branch durchsucht werden soll). Wenn ein Tree-ish gegeben wird, gibt sie die entsprechende SVN-Revisionsnummer zurück.

-B
--before

Erfordert keine exakte Übereinstimmung, wenn eine SVN-Revision angegeben wird, sondern findet den Commit, der dem Zustand des SVN-Repositorys (im aktuellen Branch) zur angegebenen Revision entspricht.

-A
--after

Erfordert keine exakte Übereinstimmung, wenn eine SVN-Revision angegeben wird; wenn keine exakte Übereinstimmung gefunden wird, wird die nächstgelegene Übereinstimmung in der Historie gesucht.

set-tree

Sie sollten erwägen, dcommit anstelle dieses Befehls zu verwenden. Committet angegebene Commit- oder Tree-Objekte nach SVN. Dies setzt voraus, dass Ihre importierten Fetch-Daten aktuell sind. Dies unternimmt keinerlei Versuche, Patches beim Committen nach SVN zu erstellen, sondern überschreibt einfach Dateien mit denen, die im Tree oder Commit angegeben sind. Alle Merges werden angenommen, dass sie unabhängig von git svn-Funktionen stattgefunden haben.

create-ignore

Sucht rekursiv nach den svn:ignore- und svn:global-ignores-Eigenschaften auf Verzeichnissen und erstellt entsprechende .gitignore-Dateien. Die resultierenden Dateien werden für den Commit vorgemerkt, aber nicht committet. Verwenden Sie -r/--revision, um eine bestimmte Revision anzugeben.

show-ignore

Sucht rekursiv nach den svn:ignore- und svn:global-ignores-Eigenschaften auf Verzeichnissen und listet diese auf. Die Ausgabe ist geeignet, an die Datei $GIT_DIR/info/exclude angehängt zu werden.

mkdirs

Versucht, leere Verzeichnisse neu zu erstellen, die der Kern-Git nicht verfolgen kann, basierend auf Informationen in den Dateien $GIT_DIR/svn/<refname>/unhandled.log. Leere Verzeichnisse werden automatisch neu erstellt, wenn "git svn clone" und "git svn rebase" verwendet werden, daher ist "mkdirs" für die Verwendung nach Befehlen wie "git checkout" oder "git reset" gedacht. (Siehe die Konfigurationsoption svn-remote.<name>.automkdirs für weitere Informationen.)

commit-diff

Committet die Diff zweier Tree-ish-Argumente von der Kommandozeile. Dieser Befehl ist nicht darauf angewiesen, sich innerhalb eines git svn init-ed Repositorys zu befinden. Dieser Befehl nimmt drei Argumente entgegen: (a) den ursprünglichen Tree, gegen den gedefft werden soll, (b) das neue Tree-Ergebnis, (c) die URL des Ziel-Subversion-Repositorys. Das letzte Argument (URL) kann weggelassen werden, wenn Sie sich in einem git svn-fähigen Repository befinden (das mit git svn init-ed wurde). Die Option -r<revision> ist hierfür erforderlich.

Die Commit-Nachricht wird entweder direkt mit der Option -m oder -F angegeben, oder indirekt aus dem Tag oder Commit, wenn der zweite Tree-ish ein solches Objekt bezeichnet, oder sie wird durch Aufrufen eines Editors angefordert (siehe Option --edit unten).

-m <msg>
--message=<msg>

Verwendet die gegebene msg als Commit-Nachricht. Diese Option deaktiviert die Option --edit.

-F <filename>
--file=<filename>

Nimmt die Commit-Nachricht aus der angegebenen Datei. Diese Option deaktiviert die Option --edit.

info

Zeigt Informationen über eine Datei oder ein Verzeichnis an, ähnlich wie 'svn info'. Unterstützt derzeit kein -r/--revision-Argument. Verwenden Sie die Option --url, um nur den Wert des Feldes URL: auszugeben.

proplist

Listet die Eigenschaften auf, die im Subversion-Repository über eine gegebene Datei oder ein Verzeichnis gespeichert sind. Verwenden Sie -r/--revision, um eine bestimmte Subversion-Revision anzugeben.

propget

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

propset

Setzt die als erstes Argument angegebene Subversion-Eigenschaft auf den als zweites Argument gegebenen Wert für die als drittes Argument gegebene Datei.

Beispiel

git svn propset svn:keywords "FreeBSD=%H" devel/py-tipper/Makefile

Dies setzt die Eigenschaft svn:keywords auf FreeBSD=%H für die Datei devel/py-tipper/Makefile.

show-externals

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

gc

Komprimiert die Dateien $GIT_DIR/svn/<refname>/unhandled.log und entfernt die Dateien $GIT_DIR/svn/<refname>/index.

reset

Macht die Auswirkungen von fetch bis zur angegebenen Revision rückgängig. Dies erlaubt Ihnen, eine SVN-Revision erneut zu fetchen. Normalerweise sollten sich die Inhalte einer SVN-Revision niemals ändern und reset sollte nicht notwendig sein. Wenn sich jedoch SVN-Berechtigungen ändern oder Sie Ihre --ignore-paths-Option ändern, kann ein fetch mit "not found in commit" (Datei zuvor nicht sichtbar) oder "checksum mismatch" (Änderung verpasst) fehlschlagen. Wenn die problematische Datei nicht für immer ignoriert werden kann (mit --ignore-paths), ist die einzige Möglichkeit, das Repo zu reparieren, reset zu verwenden.

Nur die rev_map und refs/remotes/git-svn werden geändert (siehe $GIT_DIR/svn/**/.rev_map.* im Abschnitt FILES unten für Details). Folgen Sie auf reset ein fetch und dann git reset oder git rebase, um lokale Branches auf den neuen Tree zu verschieben.

-r <n>
--revision=<n>

Gibt die jüngste Revision an, die beibehalten werden soll. Alle späteren Revisionen werden verworfen.

-p
--parent

Verwirft auch die angegebene Revision und behält stattdessen den nächstgelegenen Elternteil bei.

Beispiel

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

    r1---r2---r3 remotes/git-svn
                \
                 A---B master

Beheben Sie das ignore-paths- oder SVN-Berechtigungsproblem, das dazu geführt hat, dass "r2" überhaupt unvollständig war. Dann

git svn reset -r2 -p
git svn fetch
    r1---r2'--r3' remotes/git-svn
      \
       r2---r3---A---B master

Korrigieren Sie dann "master" mit git rebase. Verwenden Sie NICHT git merge, sonst ist Ihre Historie nicht mit einem zukünftigen dcommit kompatibel!

git rebase --onto remotes/git-svn A^ master
    r1---r2'--r3' remotes/git-svn
                \
                 A'--B' master

OPTIONEN

--shared[=(false|true|umask|group|all|world|everybody)]
--template=<template-directory>

Wird nur mit dem Befehl init verwendet. Diese werden direkt an git init übergeben.

-r <arg>
--revision <arg>

Wird mit dem Befehl fetch verwendet.

Dies erlaubt die Unterstützung von Revisionsbereichen für partielle/geschnittene Historien. $NUMBER, $NUMBER1:$NUMBER2 (numerische Bereiche), $NUMBER:HEAD und BASE:$NUMBER werden alle unterstützt.

Dies kann Ihnen erlauben, partielle Spiegel beim Ausführen von fetch zu erstellen, wird aber generell nicht empfohlen, da die Historie übersprungen und verloren geht.

-
--stdin

Wird nur mit dem Befehl set-tree verwendet.

Liest eine Liste von Commits von stdin und committet sie in umgekehrter Reihenfolge. Nur der führende sha1 wird aus jeder Zeile gelesen, daher kann die Ausgabe von git rev-list --pretty=oneline verwendet werden.

--rmdir

Wird nur mit den Befehlen dcommit, set-tree und commit-diff verwendet.

Entfernen Sie Verzeichnisse aus dem SVN-Baum, wenn keine Dateien mehr übrig sind. SVN kann leere Verzeichnisse versionieren, und diese werden standardmäßig nicht entfernt, wenn keine Dateien mehr darin enthalten sind. Git kann keine leeren Verzeichnisse versionieren. Das Aktivieren dieses Flags bewirkt, dass der Commit an SVN wie Git funktioniert.

config key: svn.rmdir
-e
--edit

Wird nur mit den Befehlen dcommit, set-tree und commit-diff verwendet.

Bearbeiten Sie die Commit-Nachricht vor dem Übertragen an SVN. Dies ist standardmäßig für Objekte, die Commits sind, deaktiviert und wird beim Übertragen von Baumobjekten erzwungen.

config key: svn.edit
-l<num>
--find-copies-harder

Wird nur mit den Befehlen dcommit, set-tree und commit-diff verwendet.

Beide werden direkt an git diff-tree übergeben; siehe git-diff-tree[1] für weitere Informationen.

config key: svn.l
config key: svn.findcopiesharder
-A<filename>
--authors-file=<filename>

Die Syntax ist mit der von git cvsimport verwendeten Datei kompatibel, aber eine leere E-Mail-Adresse kann mit <> angegeben werden.

	loginname = Joe User <user@example.com>

Wenn diese Option angegeben ist und git svn auf einen SVN-Committernamen stößt, der nicht in der Autoren-Datei vorhanden ist, wird git svn den Vorgang abbrechen. Der Benutzer muss dann den entsprechenden Eintrag hinzufügen. Das erneute Ausführen des vorherigen git svn-Befehls nach Änderung der Autoren-Datei sollte den Vorgang fortsetzen.

config key: svn.authorsfile
--authors-prog=<filename>

Wenn diese Option angegeben ist, wird für jeden SVN-Committernamen, der nicht in der Autoren-Datei vorhanden ist, die angegebene Datei mit dem Committernamen als erstem Argument ausgeführt. Das Programm soll eine einzelne Zeile der Form "Name <email>" oder "Name <>" zurückgeben, die so behandelt wird, als wäre sie in der Autoren-Datei enthalten.

Aus historischen Gründen wird ein relativer Dateiname zunächst relativ zum aktuellen Verzeichnis für init und clone gesucht und relativ zum Stammverzeichnis des Arbeitsverzeichnisses für fetch. Wenn Dateiname nicht gefunden wird, wird er wie jeder andere Befehl in $PATH gesucht.

config key: svn.authorsProg
-q
--quiet

Macht git svn weniger gesprächig. Geben Sie es ein zweites Mal an, um es noch weniger gesprächig zu machen.

-m
--merge
-s<strategy>
--strategy=<strategy>
-p
--rebase-merges

Diese werden nur mit den Befehlen dcommit und rebase verwendet.

Wird direkt an git rebase übergeben, wenn dcommit verwendet wird, falls ein git reset nicht verwendet werden kann (siehe dcommit).

-n
--dry-run

Dies kann mit den Befehlen dcommit, rebase, branch und tag verwendet werden.

Für dcommit: Gibt die Reihe von Git-Argumenten aus, die anzeigen, welche Diffs an SVN committet würden.

Für rebase: Zeigt den lokalen Branch an, der mit dem Upstream-SVN-Repository verknüpft ist, das mit dem aktuellen Branch verbunden ist, und die URL des SVN-Repositorys, von dem abgerufen wird.

Für branch und tag: Zeigt die URLs an, die beim Erstellen des Branches oder Tags zum Kopieren verwendet werden.

--use-log-author

Beim Abrufen von SVN-Commits in Git (als Teil von fetch, rebase oder dcommit-Operationen) suchen Sie nach der ersten Zeile From: oder dem Trailer Signed-off-by in der Log-Nachricht und verwenden Sie diese als Autor-Zeichenkette.

config key: svn.useLogAuthor
--add-author-from

Beim Übertragen an SVN von Git (als Teil von set-tree oder dcommit-Operationen) wird, wenn die vorhandene Log-Nachricht noch keinen From: oder Signed-off-by-Trailer hat, eine From:-Zeile basierend auf der Autor-Zeichenkette des Git-Commits angehängt. Wenn Sie dies verwenden, ruft --use-log-author einen gültigen Autor-String für alle Commits ab.

config key: svn.addAuthorFrom

ERWEITERTE OPTIONEN

-i<GIT_SVN_ID>
--id <GIT_SVN_ID>

Dies setzt GIT_SVN_ID (anstatt die Umgebung zu verwenden). Dies ermöglicht dem Benutzer, den Standard-Referenznamen zu überschreiben, von dem abgerufen wird, wenn eine einzelne URL verfolgt wird. Die Befehle log und dcommit benötigen dieses Argument nicht mehr.

-R<remote-name>
--svn-remote <remote-name>

Gibt den zu verwendenden Abschnitt [svn-remote "<remote-name>"] an. Dies ermöglicht die Verfolgung mehrerer SVN-Repositories. Standard: "svn"

--follow-parent

Diese Option ist nur relevant, wenn wir Branches verfolgen (unter Verwendung einer der Repository-Layout-Optionen --trunk, --tags, --branches, --stdlayout). Versuchen Sie für jeden verfolgten Branch herauszufinden, von woher seine Revision kopiert wurde, und setzen Sie einen geeigneten Elternteil im ersten Git-Commit für den Branch. Dies ist besonders hilfreich, wenn wir ein Verzeichnis verfolgen, das innerhalb des Repositorys verschoben wurde. Wenn diese Funktion deaktiviert ist, sind die von git svn erstellten Branches linear und teilen keine Historie, was bedeutet, dass es keine Informationen darüber gibt, woher Branches verzweigt oder zusammengeführt wurden. Das Verfolgen langer/komplizierter Verläufe kann jedoch lange dauern, daher kann das Deaktivieren dieser Funktion den Klonvorgang beschleunigen. Diese Funktion ist standardmäßig aktiviert, verwenden Sie --no-follow-parent, um sie zu deaktivieren.

config key: svn.followparent

OPTIONEN NUR FÜR KONFIGURATIONSDateien

svn.noMetadata
svn-remote.<name>.noMetadata

Dies entfernt die Zeilen git-svn-id: am Ende jedes Commits.

Diese Option kann nur für einmalige Importe verwendet werden, da git svn nicht erneut ohne Metadaten abrufen kann. Zusätzlich, wenn Sie Ihre $GIT_DIR/svn/**/.rev_map.*-Dateien verlieren, kann git svn diese nicht wiederherstellen.

Der Befehl git svn log funktioniert auf Repositorys, die dies verwenden, ebenfalls nicht. Die Verwendung dieses Befehls widerspricht der Option useSvmProps aus (hoffentlich) offensichtlichen Gründen.

Diese Option wird NICHT empfohlen, da sie es schwierig macht, alte Verweise auf SVN-Revisionsnummern in bestehender Dokumentation, Fehlerberichten und Archiven nachzuschlagen. Wenn Sie planen, von SVN zu Git zu migrieren und sicher sind, dass Sie die SVN-Historie verwerfen möchten, sollten Sie stattdessen git-filter-repo in Betracht ziehen. filter-repo ermöglicht auch die Neuformatierung von Metadaten zur besseren Lesbarkeit und die Umschreibung von Autorenschaftsinformationen für Benutzer, die nicht "svn.authorsFile" verwenden.

svn.useSvmProps
svn-remote.<name>.useSvmProps

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

Wenn eine SVN-Revision eine Eigenschaft "svm:headrev" hat, wurde die Revision wahrscheinlich von SVN::Mirror (auch von SVK verwendet) erstellt. Die Eigenschaft enthält eine Repository-UUID und eine Revision. Wir möchten, dass es so aussieht, als würden wir die ursprüngliche URL spiegeln, daher führen wir eine Hilfsfunktion ein, die die ursprüngliche Identitäts-URL und UUID zurückgibt und diese beim Generieren von Metadaten in Commit-Nachrichten verwendet.

svn.useSvnsyncProps
svn-remote.<name>.useSvnsyncprops

Ähnlich wie die Option useSvmProps; dies ist für Benutzer des svnsync(1)-Befehls, der mit SVN 1.4.x und neueren Versionen verteilt wird.

svn-remote.<name>.rewriteRoot

Dies ermöglicht Benutzern, Repositorys aus alternativen URLs zu erstellen. Zum Beispiel könnte ein Administrator git svn lokal auf dem Server ausführen (Zugriff über file://), das Repository aber mit einer öffentlichen http://- oder svn://-URL in den Metadaten verteilen, damit Benutzer diese öffentliche URL sehen.

svn-remote.<name>.rewriteUUID

Ähnlich wie die Option useSvmProps; dies ist für Benutzer, die die UUID manuell neu zuordnen müssen. Dies kann in Situationen nützlich sein, in denen die ursprüngliche UUID weder über useSvmProps noch über useSvnsyncProps verfügbar ist.

svn-remote.<name>.pushurl

Ähnlich wie Git's remote.<name>.pushurl ist dieser Schlüssel für Fälle konzipiert, in denen url über einen schreibgeschützten Transport auf ein SVN-Repository verweist, um einen alternativen Lese-/Schreibtransport bereitzustellen. Es wird davon ausgegangen, dass beide Schlüssel auf dasselbe Repository verweisen. Im Gegensatz zu commiturl ist pushurl ein Basispfad. Wenn entweder commiturl oder pushurl verwendet werden könnte, hat commiturl Vorrang.

svn.brokenSymlinkWorkaround

Dies deaktiviert potenziell aufwändige Prüfungen zur Umgehung defekter Symlinks, die von defekten Clients in SVN eingecheckt wurden. Setzen Sie diese Option auf "false", wenn Sie ein SVN-Repository mit vielen leeren Blobs verfolgen, die keine Symlinks sind. Diese Option kann geändert werden, während git svn läuft, und tritt bei der nächsten abgerufenen Revision in Kraft. Wenn sie nicht gesetzt ist, geht git svn davon aus, dass diese Option auf "true" gesetzt ist.

svn.pathnameencoding

Dies weist git svn an, Pfadnamen in eine gegebene Kodierung umzukodieren. Dies kann von Windows-Benutzern und Personen, die in Nicht-UTF-8-Lokalen arbeiten, verwendet werden, um beschädigte Dateinamen mit Nicht-ASCII-Zeichen zu vermeiden. Gültige Kodierungen sind die vom Perl-Modul Encode unterstützten.

svn-remote.<name>.automkdirs

Normalerweise versuchen die Befehle "git svn clone" und "git svn rebase", leere Verzeichnisse, die sich im Subversion-Repository befinden, neu zu erstellen. Wenn diese Option auf "false" gesetzt ist, werden leere Verzeichnisse nur erstellt, wenn der Befehl "git svn mkdirs" explizit ausgeführt wird. Wenn sie nicht gesetzt ist, geht git svn davon aus, dass diese Option auf "true" gesetzt ist.

Da die Optionen noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps und useSvmProps alle Metadaten beeinflussen, die von git svn generiert und verwendet werden; sie müssen in der Konfigurationsdatei gesetzt werden, bevor irgendeine Historie importiert wird, und diese Einstellungen sollten niemals geändert werden, sobald sie festgelegt sind.

Zusätzlich kann pro svn-remote-Abschnitt nur eine dieser Optionen verwendet werden, da sie die git-svn-id:-Metadatenzeile beeinflussen, mit Ausnahme von rewriteRoot und rewriteUUID, die zusammen verwendet werden können.

GRUNDLEGENDE BEISPIELE

Verfolgen und Beitragen zum Trunk eines Subversion-verwalteten Projekts (Tags und Branches ignorierend)

# Clone a repo (like git clone):
	git svn clone http://svn.example.com/project/trunk
# Enter the newly cloned directory:
	cd trunk
# You should be on master branch, double-check with 'git branch'
	git branch
# Do some work and commit locally to Git:
	git commit ...
# Something is committed to SVN, rebase your local changes against the
# latest changes in SVN:
	git svn rebase
# Now commit your changes (that were committed previously using Git) to SVN,
# as well as automatically updating your working HEAD:
	git svn dcommit
# Append svn:ignore and svn:global-ignores settings to the default Git exclude file:
	git svn show-ignore >> .git/info/exclude

Verfolgen und Beitragen zu einem vollständigen Subversion-verwalteten Projekt (mit Trunk, Tags und Branches)

# Clone a repo with standard SVN directory layout (like git clone):
	git svn clone http://svn.example.com/project --stdlayout --prefix svn/
# Or, if the repo uses a non-standard directory layout:
	git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/
# View all branches and tags you have cloned:
	git branch -r
# Create a new branch in SVN
	git svn branch waldo
# Reset your master to trunk (or any other branch, replacing 'trunk'
# with the appropriate name):
	git reset --hard svn/trunk
# You may only dcommit to one branch/tag/trunk at a time.  The usage
# of dcommit/rebase/show-ignore should be the same as above.

Der anfängliche git svn clone kann recht zeitaufwändig sein (insbesondere für große Subversion-Repositorys). Wenn mehrere Personen (oder eine Person mit mehreren Maschinen) git svn verwenden möchten, um mit demselben Subversion-Repository zu interagieren, können Sie den anfänglichen git svn clone auf einem Server-Repository durchführen und jeden von ihnen das Repository mit git clone klonen lassen.

# Do the initial import on a server
	ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]"
# Clone locally - make sure the refs/remotes/ space matches the server
	mkdir project
	cd project
	git init
	git remote add origin server:/pub/project
	git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
	git fetch
# Prevent fetch/pull from remote Git server in the future,
# we only want to use git svn for future updates
	git config --remove-section remote.origin
# Create a local branch from one of the branches just fetched
	git checkout -b master FETCH_HEAD
# Initialize 'git svn' locally (be sure to use the same URL and
# --stdlayout/-T/-b/-t/--prefix options as were used on server)
	git svn init http://svn.example.com/project [options...]
# Pull the latest changes from Subversion
	git svn rebase

REBASE GEGENÜBER PULL/MERGE

Bevorzugen Sie git svn rebase oder git rebase anstelle von git pull oder git merge, um nicht integrierte Commits mit einem git svn-Branch zu synchronisieren. Dadurch bleibt die Historie von nicht integrierten Commits im Hinblick auf das Upstream-SVN-Repository linear und ermöglicht die Verwendung des bevorzugten Unterbefehls git svn dcommit, um nicht integrierte Commits zurück nach SVN zu pushen.

Ursprünglich empfahl git svn, dass Entwickler vom git svn-Branch pullen oder mergen. Dies lag daran, dass der Autor git svn set-tree B zur Übertragung eines einzelnen Heads gegenüber der Notation git svn set-tree A..B zur Übertragung mehrerer Commits bevorzugte. Die Verwendung von git pull oder git merge mit git svn set-tree A..B führt dazu, dass nicht-lineare Historien beim Übertragen nach SVN abgeflacht werden, und dies kann dazu führen, dass Merge-Commits frühere Commits in SVN unerwartet umkehren.

MERGE-VERFOLGUNG

Obwohl git svn Kopierhistorien (einschließlich Branches und Tags) für Repositorys, die ein Standardlayout verwenden, verfolgen kann, kann es noch keine Merge-Historien, die innerhalb von Git stattgefunden haben, nach oben zu SVN-Benutzern darstellen. Daher wird empfohlen, die Historie innerhalb von Git so linear wie möglich zu halten, um die Kompatibilität mit SVN zu erleichtern (siehe CAVEATS-Abschnitt unten).

BEHANDLUNG VON SVN-BRANCHES

Wenn git svn so konfiguriert ist, dass Branches abgerufen werden (und --follow-branches aktiv ist), erstellt es manchmal mehrere Git-Branches für einen SVN-Branch, wobei die zusätzlichen Branches Namen der Form branchname@nnn (mit nnn einer SVN-Revisionsnummer) haben. Diese zusätzlichen Branches werden erstellt, wenn git svn keinen übergeordneten Commit für den ersten Commit in einem SVN-Branch finden kann, um den Branch mit der Historie der anderen Branches zu verbinden.

Normalerweise besteht der erste Commit in einem SVN-Branch aus einer Kopieroperation. git svn liest diesen Commit, um die SVN-Revision zu erhalten, von der der Branch erstellt wurde. Es versucht dann, den Git-Commit zu finden, der dieser SVN-Revision entspricht, und verwendet diesen als Elternteil des Branches. Es ist jedoch möglich, dass kein geeigneter Git-Commit als Elternteil dient. Dies geschieht unter anderem, wenn der SVN-Branch eine Kopie einer Revision ist, die nicht von git svn abgerufen wurde (z. B. weil es sich um eine alte Revision handelt, die mit --revision übersprungen wurde), oder wenn in SVN ein Verzeichnis kopiert wurde, das nicht von git svn verfolgt wird (wie z. B. ein Branch, der überhaupt nicht verfolgt wird, oder ein Unterverzeichnis eines verfolgten Branches). In diesen Fällen erstellt git svn immer noch einen Git-Branch, aber anstatt einen vorhandenen Git-Commit als Elternteil des Branches zu verwenden, liest es die SVN-Historie des Verzeichnisses, aus dem der Branch kopiert wurde, und erstellt entsprechende Git-Commits. Dies wird durch die Meldung "Initializing parent: <branchname>" angezeigt.

Zusätzlich wird ein spezieller Branch namens <branchname>@<SVN-Revision> erstellt, wobei <SVN-Revision> die SVN-Revisionsnummer ist, von der der Branch kopiert wurde. Dieser Branch wird auf den neu erstellten Eltern-Commit des Branches zeigen. Wenn in SVN der Branch gelöscht und später aus einer anderen Version neu erstellt wurde, wird es mehrere solcher Branches mit einem @ geben.

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

Ein Beispiel: In einem SVN-Repository mit einem Standard-Trunk/Tags/Branches-Layout wird das Verzeichnis trunk/sub in r.100 erstellt. In r.200 wird trunk/sub durch Kopieren nach branches/ verzweigt. git svn clone -s erstellt dann einen Branch sub. Es erstellt auch neue Git-Commits für r.100 bis r.199 und verwendet diese als Historie des Branches sub. Daher gibt es für jede Revision von r.100 bis r.199 zwei Git-Commits (einer enthält trunk/, einer trunk/sub/). Schließlich erstellt es einen Branch sub@200, der auf den neuen Eltern-Commit des Branches sub (d.h. den Commit für r.200 und trunk/sub/) zeigt.

HINWEISE

Zur Vereinfachung und zur Interoperabilität mit Subversion wird empfohlen, dass alle git svn-Benutzer direkt vom SVN-Server klonen, abrufen und dcommitten und alle git clone/pull/merge/push-Operationen zwischen Git-Repositorys und Branches vermeiden. Die empfohlene Methode zum Austausch von Code zwischen Git-Branches und Benutzern ist git format-patch und git am, oder einfach das 'dcommit'en in das SVN-Repository.

Das Ausführen von git merge oder git pull wird auf einem Branch, von dem Sie dcommiten möchten, NICHT empfohlen, da Subversion-Benutzer keine Merges sehen können, die Sie vorgenommen haben. Darüber hinaus kann dcommit, wenn Sie von einem Git-Branch pullen oder mergen, der ein Spiegelbild eines SVN-Branches ist, auf den falschen Branch committen.

Wenn Sie mergen, beachten Sie die folgende Regel: git svn dcommit versucht, auf dem SVN-Commit zu committen, der in

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

Sie müssen daher sicherstellen, dass der letzte Commit des Branches, den Sie dcommitten möchten, der erste Elternteil des Merges ist. Andernfalls wird es zu Chaos kommen, insbesondere wenn der erste Elternteil ein älterer Commit desselben SVN-Branches ist.

git clone klont keine Branches unter der Hierarchie refs/remotes/ oder Metadaten/Konfigurationen von git svn. Daher sollten Repositorys, die mit git svn erstellt und verwaltet werden, für das Klonen rsync verwenden, wenn überhaupt geklont werden soll.

Da dcommit intern rebase verwendet, erfordern Git-Branches, die Sie vor dcommiten nach git pushen, ein erzwungenes Überschreiben des vorhandenen Refs im Remote-Repository. Dies wird im Allgemeinen als schlechte Praxis angesehen. Weitere Einzelheiten finden Sie in der Dokumentation zu git-push[1].

Verwenden Sie nicht die Option --amend von git-commit[1] für eine Änderung, die Sie bereits gedcommittet haben. Es gilt als schlechte Praxis, Commits, die Sie bereits für andere Benutzer auf ein Remote-Repository gepusht haben, mit --amend zu bearbeiten, und dcommit mit SVN ist analog dazu.

Beim Klonen eines SVN-Repositorys, wenn keine der Optionen zur Beschreibung des Repository-Layouts verwendet wird (--trunk, --tags, --branches, --stdlayout), erstellt git svn clone ein Git-Repository mit einer vollständig linearen Historie, in der Branches und Tags als separate Verzeichnisse in der Arbeitskopie erscheinen. Obwohl dies der einfachste Weg ist, eine vollständige Kopie eines Repositorys zu erhalten, führt dies bei Projekten mit vielen Branches zu einer Arbeitskopie, die um ein Vielfaches größer ist als nur der Trunk. Daher wird für Projekte, die die Standardverzeichnisstruktur (trunk/branches/tags) verwenden, empfohlen, mit der Option --stdlayout zu klonen. Wenn das Projekt eine nicht standardmäßige Struktur verwendet und/oder Branches und Tags nicht benötigt werden, ist es am einfachsten, nur ein Verzeichnis (typischerweise Trunk) zu klonen, ohne Repository-Layout-Optionen anzugeben. Wenn die vollständige Historie mit Branches und Tags benötigt wird, müssen die Optionen --trunk / --branches / --tags verwendet werden.

Bei Verwendung mehrerer --branches oder --tags behandelt git svn Namenskollisionen nicht automatisch (z. B. wenn zwei Branches aus verschiedenen Pfaden denselben Namen haben oder wenn ein Branch und ein Tag denselben Namen haben). In diesen Fällen verwenden Sie init, um Ihr Git-Repository einzurichten, und bearbeiten Sie dann vor dem ersten fetch die Datei $GIT_DIR/config so, dass die Branches und Tags verschiedenen Namensräumen zugeordnet sind. Zum Beispiel

branches = stable/*:refs/remotes/svn/stable/*
branches = debug/*:refs/remotes/svn/debug/*

KONFIGURATION

git svn speichert [svn-remote]-Konfigurationsinformationen in der Datei $GIT_DIR/config des Repositorys. Sie ähnelt den Kern-Git-[remote]-Abschnitten, außer dass fetch-Schlüssel keine Glob-Argumente akzeptieren; stattdessen werden sie von den Schlüsseln branches und tags behandelt. Da einige SVN-Repositorys seltsam mit mehreren Projekten konfiguriert sind, werden Glob-Erweiterungen wie die unten aufgeführten zugelassen.

[svn-remote "project-a"]
	url = http://server.org/svn
	fetch = trunk/project-a:refs/remotes/project-a/trunk
	branches = branches/*/project-a:refs/remotes/project-a/branches/*
	branches = branches/release_*:refs/remotes/project-a/branches/release_*
	branches = branches/re*se:refs/remotes/project-a/branches/*
	tags = tags/*/project-a:refs/remotes/project-a/tags/*

Beachten Sie, dass der * (Sternchen)-Wildcard des lokalen Refs (rechts von :) der am weitesten rechts liegende Pfadkomponente sein muss; der Remote-Wildcard kann jedoch überall sein, solange er eine unabhängige Pfadkomponente ist (umgeben von / oder EOL). Diese Art von Konfiguration wird nicht automatisch von init erstellt und sollte manuell mit einem Texteditor oder über git config eingegeben werden.

Beachten Sie auch, dass pro Wort nur ein Sternchen erlaubt ist. Zum Beispiel

branches = branches/re*se:refs/remotes/project-a/branches/*

stimmt mit den Branches release, rese, re123se überein, jedoch

branches = branches/re*s*e:refs/remotes/project-a/branches/*

führt zu einem Fehler.

Es ist auch möglich, eine Teilmenge von Branches oder Tags abzurufen, indem eine durch Kommas getrennte Liste von Namen in geschweiften Klammern verwendet wird. Zum Beispiel

[svn-remote "huge-project"]
	url = http://server.org/svn
	fetch = trunk/src:refs/remotes/trunk
	branches = branches/{red,green}/src:refs/remotes/project-a/branches/*
	tags = tags/{1.0,2.0}/src:refs/remotes/project-a/tags/*

Mehrere fetch-, branches- und tags-Schlüssel werden unterstützt.

[svn-remote "messy-repo"]
	url = http://server.org/svn
	fetch = trunk/project-a:refs/remotes/project-a/trunk
	fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
	branches = branches/server/*:refs/remotes/project-a/branches/*
	branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
	tags = tags/server/*:refs/remotes/project-a/tags/*

Das Erstellen eines Branches in einer solchen Konfiguration erfordert eine Disambiguierung, welcher Speicherort verwendet werden soll, indem die Flagge -d oder --destination verwendet wird.

$ git svn branch -d branches/server release-2-3-0

Beachten Sie, dass git-svn die höchste Revision verfolgt, in der ein Branch oder Tag aufgetreten ist. Wenn die Teilmenge von Branches oder Tags nach dem Abrufen geändert wird, muss $GIT_DIR/svn/.metadata manuell bearbeitet werden, um branches-maxRev und/oder tags-maxRev entsprechend zu entfernen (oder zurückzusetzen).

DATEIEN

$GIT_DIR/svn/**/.rev_map.*

Zuordnung zwischen Subversion-Revisionsnummern und Git-Commit-Namen. In einem Repository, in dem die Option noMetadata nicht gesetzt ist, kann dies aus den git-svn-id:-Zeilen am Ende jedes Commits wiederhergestellt werden (siehe svn.noMetadata-Abschnitt oben für Details).

git svn fetch und git svn rebase aktualisieren die rev_map automatisch, wenn sie fehlt oder nicht aktuell ist. git svn reset spult sie automatisch zurück.

BUGS

Wir ignorieren alle SVN-Eigenschaften außer svn:executable. Alle unbehandelten Eigenschaften werden nach $GIT_DIR/svn/<refname>/unhandled.log geloggt.

Umbenannte und kopierte Verzeichnisse werden von Git nicht erkannt und daher beim Übertragen nach SVN nicht verfolgt. Ich habe nicht vor, Unterstützung dafür hinzuzufügen, da es ziemlich schwierig und zeitaufwändig ist, es für alle möglichen Eckfälle zum Laufen zu bringen (Git tut es auch nicht). Das Übertragen von umbenannten und kopierten Dateien wird vollständig unterstützt, wenn sie ähnlich genug sind, dass Git sie erkennt.

In SVN ist es möglich (wenn auch nicht empfohlen), Änderungen an einem Tag vorzunehmen (da ein Tag nur eine Verzeichniskopie ist, technisch gesehen also dasselbe wie ein Branch). Beim Klonen eines SVN-Repositorys kann git svn nicht wissen, ob ein solcher Commit an einem Tag in Zukunft erfolgen wird. Daher agiert es konservativ und importiert alle SVN-Tags als Branches, wobei der Tag-Name mit tags/ vorangestellt wird.

SIEHE AUCH

git-rebase[1]

GIT

Teil der git[1] Suite