Ein SVN-Repository, das ich über git-svn spiegele, hat die URL geändert.
In Vanilla SVN würden Sie einfach tun svn switch --relocate old_url_base new_url_base
.
Wie kann ich das mit git-svn machen?
Das einfache Ändern der SVN-URL in der Konfigurationsdatei schlägt fehl.
Antworten:
Das geht ziemlich gut mit meiner Situation um:
https://git.wiki.kernel.org/index.php/GitSvnSwitch
Ich habe mit dem
file://
Protokoll geklont und wollte zumhttp://
Protokoll wechseln .Es ist verlockend, die
url
Einstellung im[svn-remote "svn"]
Abschnitt von zu bearbeiten.git/config
, aber allein funktioniert dies nicht. Im Allgemeinen müssen Sie wie folgt vorgehen:url
Einstellung svn-remote auf den neuen Namen um.git svn fetch
. Dies muss mindestens eine neue Revision von svn abrufen!url
Einstellung von svn-remote wieder in die ursprüngliche URL.git svn rebase -l
diese Option aus, um eine lokale Rebase durchzuführen (mit den Änderungen, die beim letzten Abruf vorgenommen wurden).url
Einstellung von svn-remote wieder in die neue URL.git svn rebase
sollte wieder funktionieren.Abenteuerlustige möchten es vielleicht versuchen
--rewrite-root
.quelle
Sie können sehen, ob Folgendes in Ordnung ist:
Wenn
svn-remote.svn.rewriteRoot
in config file (.git/config
) nicht vorhanden :Wenn
svn-remote.svn.rewriteUUID
in der Konfigurationsdatei nicht vorhanden:Die
currentRepositoryUUID
erhalten Sie von.git/svn/.metadata
.git config svn-remote.svn.url <newRepositoryURL>
quelle
file://
, wechseln zusvn+ssh
); Nur um Folgendes zu beachten: Diese Prozedur muss nicht "mindestens eine neue Revision von svn abrufen"; auch./.git/svn/.metadata
nach dem erstensvn rebase
enthält das<newRepository>
asreposRoot
- aber dies reicht nicht aus, um dierewrite*
Schlüssel von zu entfernen.git/config
; Daher sollten diese Schlüssel, soweit ich das verstehe, dauerhaft dort aufbewahrt werden.svn+ssh://
und unser SVN-Server hat gerade die Domain von.se
auf geändert.com
, um unsere interne Benennung zu bereinigen.Leider funktionieren die meisten Links in diesen Antworten nicht, daher werde ich ein paar Informationen aus dem Git-Wiki duplizieren, um später darauf zurückgreifen zu können.
Diese Lösung hat bei mir funktioniert:
Bearbeiten Sie den
svn-remote
url
(oderfetch
Pfad) in.git/config
, um auf die neue Domäne / URL / den neuen Pfad zu verweisenFühren Sie git aus
git svn fetch
. Dies muss mindestens eine neue Revision von svn abrufen!Wenn Sie es
git svn rebase
jetzt versuchen , wird folgende Fehlermeldung angezeigt:Ich denke, das liegt daran
git svn
, dass die Tatsache verwirrt ist, dass Ihr letztes Commit vor dem Abrufgit-svn-id
auf den alten Pfad verweist, der nicht mit dem in übereinstimmt.git/config
.Um dieses Problem zu umgehen, ändern Sie
svn-remote
url
(oder denfetch
Pfad) zurück zur ursprünglichen Domäne / URL / PfadFühren Sie nun
git svn rebase -l
erneut aus, um eine lokale Rebase mit den Änderungen durchzuführen, die beim letzten Abruf vorgenommen wurden. Diesmal war es wird funktionieren, offenbar , weilgit svn
nicht von der Tatsache verwechselt werden , dass diegit-svn-id
von dem neuen Leiter nicht mit vorgefundener passt in.git/config
.Schließlich ändern
svn-remote
url
(oderfetch
Pfad) zurück auf die neue Domain / url / pathAn dieser Stelle
git svn rebase
sollte wieder funktionieren!Die Originalinformationen wurden hier gefunden .
quelle
Git svn stützt sich stark auf die svn-URL. Jedes Commit, das aus svn importiert wird
git-svn-id
, enthält eine , die die svn-URL enthält.Eine gültige Umzugsstrategie besteht darin,
git-svn clone
das neue Repository aufzurufen und die Änderungen in diesem neuen Abschluss zusammenzuführen. Eine ausführlichere Vorgehensweise finden Sie in diesem Artikel:http://www.sanityinc.com/articles/relocating-git-svn-repositories
quelle
git filter-branch
Dieses Skript aus einem Blogeintrag hat für mich funktioniert. Geben Sie die alte und die neue Repo-URL als Parameter an, genau wie für
svn switch --relocate
.Das Skript ruft
git filter-branch
auf, um Subversion-URLs in dengit-svn-id
Commit-Nachrichten zu ersetzen , aktualisiert.git/config
und aktualisiertgit-svn
Metadaten, indem es sie mithilfe neu erstelltgit svn rebase
. Während diesgit svn clone
möglicherweise die robustere Lösung ist,filter-branch
funktioniert der Ansatz für große Repositorys (Stunden gegenüber Tagen) viel schneller.quelle
git_fast_filter
Noch schneller als
git-filter-branch
(dh Minuten statt Stunden), aber im Geiste ähnlich, ist zu verwendengit_fast_filter
. Dies erfordert jedoch etwas mehr Codierung, und es gibt keine saubere, fertig verpackte Lösung. Im Gegensatzgit-filter-branch
dazu wird dadurch ein neues Repo aus einem alten erstellt . Es wird angenommen, dass diesmaster
auf das letzte SVN-Commit verweist.git_fast_filter
aus dem Gitorious Repo.git_fast_filter
basierend auf diesem Gist geklont haben , und setzen Sie das ausführbare Bit mitchmod +x
. Passen Sie alte und neue Repository-Pfade an. (Der Inhalt des Skripts wird ebenfalls unten eingefügt.)git init
und ändern Sie das Arbeitsverzeichnis in dieses neue Repo.Führen Sie die folgende Pipe aus:
Kopieren Sie
.git/config
möglicherweise andere relevante Dateien.git/info
vom alten Repo in das neue Repo..git/svn
.Beachten Sie
git-svn
die neue Zuordnung der RevisionsnummernAusführen
git branch refs/remotes/git-svn master
refs/remotes/git-svn
, konsultieren.git/config
,svn-remote
AbschnitteAusführen
git svn info
. Wenn dieser Befehl einfriert, stimmt etwas nicht. Die Zuordnung der Revisionsnummern sollte neu erstellt werden.Entfernen Sie den gefälschten Zweig
refs/remotes/git-svn
, er wird von neu erstelltgit-svn
git svn rebase
.Nachfolgend finden Sie den Inhalt von
commit_filter.py
, ersetzen Sie die Werte vonIN_REPO
undOUT_REPO
gegebenenfalls:quelle
Die obige
git svn rebase -l
Lösung hat bei mir nicht funktioniert. Ich beschloss, es anders zu machen:old
und neues SVN in Git-Reponew
old
innew
cd new
git fetch ../old
git tag old FETCH_HEAD
new
oben aufold
(sollte erfolgreich sein, da die Bäume in der Wurzelnew
und der Spitze vonold
identisch sind)git checkout master
(Angenommen, dermaster
Zweig zeigt auf den SVN-Kopf. Dies ist bei einem sauberen Klon der Fall. Andernfalls müssen Sie vor dem Start einen Commit durchführen.)git rebase --root --onto old
new
, um die Rebase zu berücksichtigengit update-ref --no-deref refs/remotes/git-svn master
(stellen Sie den Remote - ref je nachdem , wie Sie geklont, zum Beispiel könnte es seinrefs/remotes/svn/trunk
)rm -r .git/svn
git svn info
quelle
Basierend auf einigen anderen Antworten auf diese Frage habe ich ein Ruby-Skript entwickelt, das das Verschieben von git-svn behandelt. Sie finden es unter https://gist.github.com/henderea/6e779b66be3580c9a584 .
Es behandelt das Verschieben, ohne eine andere Kopie auszuchecken, und es behandelt sogar den Fall, dass es in einem oder mehreren Zweigen nicht gedrückte Änderungen gibt (da dies die reguläre Logik verletzt). Es werden Inhalte aus der Git-Filter-Zweig-Antwort (für die Hauptlogik) und der Antwort zum Kopieren von Zweigen von einer Instanz des Repos in eine andere (zum Kopieren von Zweigen mit nicht übertragenen Änderungen) verwendet.
Ich habe dies verwendet, um eine Reihe von Git-SVN-Repos zu verschieben, die ich für die Arbeit habe, und diese Version des Skripts (ich habe unzählige Iterationen durchlaufen) scheint für mich zu funktionieren. Es ist nicht superschnell, aber es scheint alle Fälle zu behandeln, auf die ich gestoßen bin, und führt zu einem vollständig verlagerten Repo.
Das Skript bietet Ihnen die Möglichkeit, eine Kopie des Repos zu erstellen, bevor Sie Änderungen vornehmen. Mit dieser Option können Sie ein Backup erstellen. Das Erstellen einer Kopie ist erforderlich, wenn Sie Änderungen in einem Zweig nicht verschoben haben.
Das Skript verwendet keine Edelsteine oder andere Bibliotheken, die nicht in der normalen MRI Ruby-Installation enthalten sind. Es werden die in der MRT enthaltenen Bibliotheken readline und fileutils verwendet.
Hoffentlich wird sich mein Skript für jemand anderen als nützlich erweisen. Fühlen Sie sich frei, Änderungen am Skript vorzunehmen.
HINWEIS: Ich habe dieses Skript nur mit Git 2.3.0 / 2.3.1 und Ruby 2.2.0 unter OS X 10.10 Yosemite getestet (da dies die von mir verwendete Umgebung ist), aber ich würde erwarten, dass es auch in anderen Umgebungen funktioniert. Keine Garantie für Windows.
quelle