Wie migriere ich ein SVN-Repository mit Verlauf in ein neues Git-Repository?

Erstellen Sie eine Benutzerdatei (d. H. users.txt), um SVN-Benutzer Git zuzuordnen:

user1 = First Last Name <[email protected]>
user2 = First Last Name <[email protected]>
...

Mit diesem Einzeiler können Sie eine Vorlage aus Ihrem vorhandenen SVN-Repository erstellen:

svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > users.txt

SVN wird angehalten, wenn ein fehlender SVN-Benutzer nicht in der Datei gefunden wird. Danach können Sie die Datei aktualisieren und dort weitermachen, wo Sie aufgehört haben.

Ziehen Sie nun die SVN-Daten aus dem Repository:

git svn clone --stdlayout --no-metadata --authors-file=users.txt svn://hostname/path dest_dir-tmp

Dieser Befehl erstellt ein neues Git-Repository in dest_dir-tmp und beginnt mit dem Abrufen des SVN-Repositorys. Beachten Sie, dass das Flag "--stdlayout" impliziert, dass Sie das allgemeine SVN-Layout "trunk /, branches /, tags /" haben. Wenn sich Ihr Layout unterscheidet, machen Sie sich mit den Optionen --tags, --branches, --trunk vertraut (im Allgemeinen git svn help).

Alle gängigen Protokolle sind zulässig: svn://, http://, https://. Die URL sollte auf das Basis-Repository abzielen, etwa http://svn.mycompany.com/myrepo/repository . Das darf nicht /trunk, /tag oder /branches beinhalten.

Beachten Sie, dass es nach der Ausführung dieses Befehls sehr oft aussieht, als ob die Operation "hängen geblieben/eingefroren" ist, und es ist ganz normal, dass sie nach der Initialisierung des neuen Repositorys für lange Zeit hängen bleibt. Schließlich sehen Sie dann Protokollmeldungen, die darauf hinweisen, dass die Migration durchgeführt wird.

Beachten Sie auch, dass Git, wenn Sie das --no-metadata -Flag weglassen, Informationen zur entsprechenden SVN-Revision an die Festschreibungsnachricht anfügt (d. H. git-svn-id: svn://svn.mycompany.com/myrepo/<branchname/trunk>@<RevisionNumber> <Repository UUID>).

Wenn kein Benutzername gefunden wird, aktualisieren Sie Ihre users.txt -Datei wie folgt:

cd dest_dir-tmp
git svn fetch

Wenn Sie ein großes Projekt haben, müssen Sie diesen letzten Befehl möglicherweise mehrmals wiederholen, bis alle Subversion-Commits abgerufen wurden:

git svn fetch

Wenn der Vorgang abgeschlossen ist, checkt Git die SVN trunk in einen neuen Zweig aus. Alle anderen Zweige werden als Fernbedienungen eingerichtet. Sie können die anderen SVN-Filialen anzeigen mit:

git branch -r

Wenn Sie andere entfernte Zweige in Ihrem Repository behalten möchten, möchten Sie für jeden manuell einen lokalen Zweig erstellen. (Trunk/Master überspringen.) Wenn Sie dies nicht tun, werden die Zweige im letzten Schritt nicht geklont.

git checkout -b local_branch remote_branch
# It's OK if local_branch and remote_branch are the same name

Tags werden als Zweige importiert. Sie müssen eine lokale Verzweigung erstellen, ein Tag erstellen und die Verzweigung löschen, um sie als Tags in Git zu haben. So machen Sie es mit dem Tag "v1":

git checkout -b tag_v1 remotes/tags/v1
git checkout master
git tag v1 tag_v1
git branch -D tag_v1

Klonen Sie Ihr GIT-SVN-Repository in ein sauberes Git-Repository:

git clone dest_dir-tmp dest_dir
rm -rf dest_dir-tmp
cd dest_dir

Die lokalen Zweige, die Sie zuvor aus Remote-Zweigen erstellt haben, wurden nur als Remote-Zweige in das neue geklonte Repository kopiert. (Trunk/Master überspringen.) Für jeden Zweig, den Sie behalten möchten:

git checkout -b local_branch Origin/remote_branch

Entfernen Sie abschließend die Fernbedienung aus Ihrem sauberen Git-Repository, die auf das jetzt gelöschte temporäre Repository verweist:

git remote rm Origin

Subversion-Repository sauber in ein Git-Repository migrieren . Zuerst müssen Sie eine Datei erstellen, die die Namen Ihrer Subversion-Commit-Autoren den Git-Commitern zuordnet, z. B. ~/authors.txt:

jmaddox = Jon Maddox <[email protected]>
bigpappa = Brian Biggs <[email protected]>

Dann können Sie die Subversion-Daten in ein Git-Repository herunterladen:

mkdir repo && cd repo
git svn init http://Subversion/repo --no-metadata
git config svn.authorsfile ~/authors.txt
git svn fetch

Wenn Sie einen Mac verwenden, können Sie git-svn von MacPorts beziehen, indem Sie git-core +svn installieren.

Befindet sich Ihr Subversion-Repository auf demselben Computer wie Ihr gewünschtes Git-Repository, können Sie diese Syntax für den Init-Schritt verwenden, andernfalls gilt Folgendes:

git svn init file:///home/user/repoName --no-metadata

Ich habe das svn2git-Skript verwendet und es funktioniert wie ein Zauber.

Ich empfehle, sich mit Git vertraut zu machen, bevor Sie versuchen, git-svn ständig zu verwenden, d. H. SVN als zentrales Repo beizubehalten und Git lokal zu verwenden.

Für eine einfache Migration mit dem gesamten Verlauf sind jedoch die folgenden einfachen Schritte erforderlich:

Initialisiere das lokale Repo:

mkdir project
cd project
git svn init http://svn.url

Markieren Sie, wie weit zurück Sie mit dem Importieren von Revisionen beginnen möchten:

git svn fetch -r42

(oder einfach "git svn fetch" für alle Umdrehungen)

Eigentlich alles abrufen seitdem:

git svn rebase

Sie können das Ergebnis des Imports mit Gitk überprüfen. Ich bin nicht sicher, ob dies unter Windows funktioniert, es funktioniert unter OSX und Linux:

gitk

Wenn Sie Ihr SVN-Repo lokal geklont haben, können Sie es zur einfacheren Zusammenarbeit auf ein zentrales Git-Repo übertragen.

Erstellen Sie zuerst Ihr leeres Remote-Repo (vielleicht am GitHub ?):

git remote add Origin [email protected]:user/project-name.git

Synchronisieren Sie dann optional Ihren Hauptzweig, damit der Pull-Vorgang den Remote-Master automatisch mit Ihrem lokalen Master zusammenführt, wenn beide neue Inhalte enthalten:

git config branch.master.remote Origin
git config branch.master.merge refs/heads/master

Danach könnten Sie daran interessiert sein, mein eigenes git_remote_branch -Tool auszuprobieren, das den Umgang mit entfernten Zweigen erleichtert:

Erster erklärender Beitrag: " Git remote branches "

Follow-up für die neueste Version: " Zeit für die Zusammenarbeit mit git_remote_branch "

Es gibt eine neue Lösung für die reibungslose Migration von Subversion nach Git (oder für die gleichzeitige Verwendung beider): SubGit .

Ich arbeite selbst an diesem Projekt. Wir verwenden SubGit in unseren Repositories - einige meiner Teamkollegen verwenden Git und einige Subversion und bis jetzt funktioniert es sehr gut.

Um mit SubGit von Subversion nach Git zu migrieren, müssen Sie Folgendes ausführen:

$ subgit install svn_repos
...
TRANSLATION SUCCESSFUL 

Danach erhalten Sie das Git-Repository in svn_repos/.git und können es klonen oder Subversion und dieses neue Git-Repository weiterhin zusammen verwenden: SubGit stellt sicher, dass beide immer synchron bleiben.

Falls Ihr Subversion-Repository mehrere Projekte enthält, werden mehrere Git-Repositorys im Verzeichnis svn_repos/git erstellt. So passen Sie die Übersetzung vor dem Ausführen an:

$ subgit configure svn_repos
$ edit svn_repos/conf/subgit.conf (change mapping, add authors mapping, etc)
$ subgit install svn_repos

Mit SubGit können Sie zu reinem Git (nicht git-svn) migrieren und es verwenden, während Sie Subversion so lange behalten, wie Sie es benötigen (zum Beispiel für Ihre bereits konfigurierten Build-Tools).

Hoffe das hilft!

Siehe die offizielle git-svn manpage . Schauen Sie sich insbesondere unter "Grundlegende Beispiele" um:

Verfolgung und Mitwirkung an einem gesamten von Subversion verwalteten Projekt (einschließlich Trunk, Tags und Zweigen):

# Clone a repo (like git clone):
    git svn clone http://svn.foo.org/project -T trunk -b branches -t tags

Pro Git 8.2 erklärt es: http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git

SubGit (gegen Blue Screen of Death)

subgit import --svn-url url://svn.serv/Bla/Bla  directory/path/Local.git.Repo

Es ist alles.

+ Zum Aktualisieren von SVN, einem Git-Repository, das mit dem ersten Befehl erstellt wurde.

subgit import  directory/path/Local.git.Repo

Ich habe eine Möglichkeit genutzt, um sofort nach Git zu migrieren und ein riesiges Repository zu erhalten.
Natürlich brauchst du etwas Vorbereitung.
Aber Sie können den Entwicklungsprozess überhaupt nicht stoppen.

Hier ist mein Weg.

Meine Lösung sieht so aus:

• SVN in ein Git-Repository migrieren
• Aktualisiere das Git-Repository kurz bevor das Team zu wechselt.

Die Migration benötigt viel Zeit für ein großes SVN-Repository.
Aber die Aktualisierung der abgeschlossenen Migration dauert nur wenige Sekunden.

Natürlich benutze ich SubGit , Mama. Git-Svn macht mich Blue Screen of Death . Einfach ständig. Und git-svn langweilt mich mit Gits " Dateiname zu lang " schwerwiegendem Fehler.

STEPS

1. SubGit herunterladen

2. Bereiten Sie Migrations- und Aktualisierungsbefehle vor.

Nehmen wir an, wir machen es für Windows (es ist trivial, auf Linux zu portieren).
Erstellen Sie in einem SubGit-Installationsverzeichnis bin (subgit-2.X.X\bin) zwei .bat-Dateien.

Inhalt einer Datei/eines Befehls für die Migration:

start    subgit import --svn-url url://svn.serv/Bla/Bla  directory/path/Local.git.Repo

Der Befehl "Start" ist hier optional (Windows). Es wird erlauben, Fehler beim Start zu sehen und eine Shell nach Abschluss des SubGit geöffnet zu lassen.

Sie können hier hinzufügen zusätzliche Parameter ähnlich wie bei git-svn . Ich verwende nur - default-domain myCompanyDomain.com , um die Domain der E-Mail-Adresse von SVN-Autoren zu reparieren.
Ich habe die Standardstruktur des SVN-Repositorys (Trunk/Branches/Tags) und wir hatten keine Probleme mit der "Autoren-Zuordnung". Also mache ich nichts mehr.

(Wenn Sie Tags wie Zweige migrieren möchten oder Ihr SVN mehrere Zweige/Tags-Ordner hat, können Sie das ausführlichere SubGit verwenden Ansatz )

Tipp 1 : Verwenden Sie --minimal-revision YourSvnRevNumber, um schnell zu sehen, wie sich die Dinge entwickeln (eine Art Debugging). Besonders nützlich ist es, aufgelöste Autorennamen oder E-Mails anzuzeigen.
Oder um die Tiefe des Migrationsverlaufs zu begrenzen.

Tipp 2 : Die Migration kann unterbrochen werden (Ctrl + C) und durch Ausführen des nächsten Aktualisierungsbefehls/der nächsten Datei wiederhergestellt.
Ich rate nicht dazu, dies für große Repositories zu tun. Ich habe "Nicht genügend Speicher für Java + Windows-Ausnahme" erhalten.

Tipp 3 : Erstellen Sie besser eine Kopie Ihres Ergebnis-Bare-Repositorys.

Inhalt einer Datei/eines Befehls zum Aktualisieren:

start    subgit import  directory/path/Local.git.Repo

Sie können es beliebig oft ausführen, wenn Sie die Commits des letzten Teams für Ihr Git-Repository erhalten möchten.

Achtung! Berühren Sie nicht Ihr nacktes Repository (z. B. das Erstellen von Zweigen).
Sie werden den nächsten schwerwiegenden Fehler nehmen:

Nicht behebbarer Fehler: Sind nicht synchron und können nicht synchronisiert werden ... Übersetzen von Subversion-Revisionen in Git-Commits ...

3. Führen Sie den ersten Befehl/die erste Datei aus. Es wird lange dauern, bis ein großes Depot fertig ist. 30 Stunden für mein bescheidenes Depot.

Es ist alles.
Sie können Ihr Git-Repository jederzeit über SVN aktualisieren, indem Sie den zweiten Befehl/die zweite Datei ausführen. Und bevor Sie Ihr Entwicklungsteam auf Git umstellen.
Es dauert nur Sekunden.

Es gibt noch eine weitere nützliche Aufgabe.

Verschieben Sie Ihr lokales Git-Repository in ein entferntes Git-Repository

Ist es dein Fall? Lass uns weitermachen.

1. Konfigurieren Sie Ihre Fernbedienungen

Lauf:

$ git remote add Origin url://your/repo.git

2. Bereiten Sie das erste Senden Ihres riesigen lokalen Git-Repositorys an ein Remote-Repository vor

Standardmäßig kann Ihr Git keine großen Stücke senden. fatal: Das entfernte Ende hat unerwartet aufgelegt

Lass uns loslegen:

git config --global http.postBuffer 1073741824

524288000 - 500 MB 1073741824 - 1 GB usw.

Korrigieren Sie Ihr lokales Zertifikatsprobleme . Wenn Ihr Git-Server ein kaputtes Zertifikat verwendet.

Ich habe Zertifikate deaktiviert.

Ihr Git-Server hat möglicherweise auch ein Einschränkungen der Anforderungsmenge müssen korrigiert werden .

3. Gesamte Migration pushen zum entfernten Git-Repository des Teams.

Führen Sie mit einem lokalen Git aus:

git Push Origin --mirror

( git Push Origin '*: *' für alte Git-Versionen)

Wenn Sie folgendes erhalten: Fehler: Kann git nicht erzeugen: Keine solche Datei oder Verzeichnis ... Für mich löst die vollständige Neuerstellung meines Repository diesen Fehler ( 30 Stunden). Sie können die nächsten Befehle versuchen

git Push Origin --all
git Push Origin --tags

Oder versuchen Sie Git neu installieren ( für mich nutzlos ). Oder Sie erstellen Zweige aus all Ihren Tags und verschieben sie. Oder, oder, oder ...

reposurgeon

In komplizierten Fällen ist der Reposurgeon von Eric S. Raymond das Werkzeug der Wahl. Zusätzlich zu SVN werden viele andere Versionskontrollsysteme über das fast-export -Format sowie CVS unterstützt. Der Autor berichtet über erfolgreiche Konvertierungen von alten Repositories wie Emacs und FreeBSD .

Das Tool zielt anscheinend auf eine nahezu perfekte Konvertierung ab (z. B. das Konvertieren der svn:ignore -Eigenschaften von SVN in .gitignore -Dateien), auch für schwierige Repository-Layouts mit einer langen Geschichte. In vielen Fällen sind andere Tools möglicherweise einfacher zu verwenden.

Lesen Sie vor dem Lesen der Dokumentation der Befehlszeile reposurgeon unbedingt die ausgezeichnete DVCS-Migrationsanleitung , die den Konvertierungsprozess Schritt für Schritt durchläuft Schritt.

Dieser Leitfaden auf der Website von atlassian ist einer der besten, den ich gefunden habe:

https://www.atlassian.com/git/migration

Dieses Tool - https://bitbucket.org/atlassian/svn-migration-scripts - ist unter anderem auch sehr nützlich, um eine author.txt zu generieren.

Sie müssen installieren

git
git-svn

Von diesem Link kopiert http://john.albin.net/git/convert-Subversion-to-git .

1. Liste aller Subversion-Committer abrufen

Subversion listet einfach den Benutzernamen für jedes Commit auf. Die Commits von Git enthalten viel umfangreichere Daten, aber im einfachsten Fall muss der Commit-Autor einen Namen und eine E-Mail-Adresse haben. Standardmäßig listet das Tool git-svn nur den SVN-Benutzernamen in den Feldern "Autor" und "E-Mail" auf. Aber mit ein wenig Arbeit können Sie eine Liste aller SVN-Benutzer und deren entsprechenden Git-Namen und E-Mails erstellen. Diese Liste kann von git-svn verwendet werden, um einfache svn-Benutzernamen in richtige Git-Committer umzuwandeln.

Führen Sie im Stammverzeichnis Ihrer lokalen Subversion-Kaufabwicklung den folgenden Befehl aus:

svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors-transform.txt

Dadurch werden alle Protokollnachrichten abgerufen, die Benutzernamen herausgefiltert, doppelte Benutzernamen entfernt, die Benutzernamen sortiert und in eine Datei mit dem Namen „artists-transform.txt“ eingefügt. Bearbeiten Sie nun jede Zeile in der Datei. Zum Beispiel konvertieren:

jwilkins = jwilkins <jwilkins>

das mögen:

jwilkins = John Albin Wilkins <[email protected]>

2. Klonen Sie das Subversion-Repository mit git-svn

git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt --stdlayout ~/temp

Dadurch wird die Standard-git-svn-Transformation ausgeführt (unter Verwendung der in Schritt 1 erstellten Datei "authors-transform.txt") und das git-Repository im Ordner "~/temp" in Ihrem Ausgangsverzeichnis abgelegt.

3. Konvertiere svn: ignore Eigenschaften in .gitignore

Wenn Ihr SVN-Repository SVN: Ignoriereigenschaften verwendet, können Sie diese problemlos in eine .gitignore-Datei konvertieren. Verwenden Sie dazu:

cd ~/temp
git svn show-ignore > .gitignore
git add .gitignore
git commit -m 'Convert svn:ignore properties to .gitignore.'

4. Repository in ein Bare-Git-Repository verschieben

Erstellen Sie zunächst ein nacktes Repository und stellen Sie sicher, dass der Standardzweig mit dem Namen des SVN-Trunk-Zweigs übereinstimmt.

git init --bare ~/new-bare.git
cd ~/new-bare.git
git symbolic-ref HEAD refs/heads/trunk

Verschieben Sie dann das temporäre Repository in das neue leere Repository.

cd ~/temp
git remote add bare ~/new-bare.git
git config remote.bare.Push 'refs/remotes/*:refs/heads/*'
git Push bare

Sie können das ~/temp-Repository jetzt sicher löschen.

5. Benenne den "Trunk" Zweig um in "Master"

Ihr Hauptentwicklungszweig erhält den Namen "trunk", der dem Namen in Subversion entspricht. Sie möchten es in den Standard-"Master" -Zweig von Git umbenennen, indem Sie Folgendes verwenden:

cd ~/new-bare.git
git branch -m trunk master

6. Bereinigen von Zweigen und Tags

mit git-svn werden alle Subversions-Tags zu sehr kurzen Zweigen in Git mit der Form „tags/name“. Sie möchten alle diese Zweige in tatsächliche Git-Tags konvertieren, indem Sie Folgendes verwenden:

cd ~/new-bare.git
git for-each-ref --format='%(refname)' refs/heads/tags |
cut -d / -f 4 |
while read ref
do
  git tag "$ref" "refs/heads/tags/$ref";
  git branch -D "tags/$ref";
done

Dieser Schritt erfordert einige Eingaben. :-) Aber keine Sorge; Ihre Unix-Shell bietet eine> sekundäre Eingabeaufforderung für den überlangen Befehl, der mit git for-each-ref beginnt.

Eine etwas erweiterte Antwort mit nur Git, SVN und Bash. Es enthält Schritte für SVN-Repositorys, die nicht das herkömmliche Layout mit einem Trunk/Branches/Tags-Verzeichnislayout verwenden (SVN erzwingt absolut nichts für diese Art von Layout).

Verwenden Sie zuerst dieses Bash-Skript, um Ihr SVN-Repo nach den verschiedenen Personen zu durchsuchen, die beigetragen haben, und um eine Vorlage für eine Zuordnungsdatei zu generieren:

_#!/usr/bin/env bash
authors=$(svn log -q | grep -e '^r' | awk 'BEGIN { FS = "|" } ; { print $2 }' | sort | uniq)
for author in ${authors}; do
  echo "${author} = NAME <[email protected]>";
done
_

Verwenden Sie diese Option, um eine authors -Datei zu erstellen, in der Sie Benutzernamen und E-Mails mithilfe von git config properties _user.name_ und _user.email_ svn-Benutzernamen zuordnen. (Beachten Sie, dass es für einen Dienst wie GitHub ausreicht, nur eine passende E-Mail zu haben).

Dann lassen Sie git svn das svn-Repository in ein git-Repository klonen und ihm die Zuordnung mitteilen:

_git svn clone --authors-file=authors --stdlayout svn://example.org/Folder/projectroot_

Dies kann unglaublich lange dauern, da git svn jede Revision für jedes vorhandene Tag oder jeden Zweig einzeln überprüft. (Beachten Sie, dass Tags in SVN nur echte Verzweigungen sind und daher in Git als solche enden). Sie können dies beschleunigen, indem Sie alte Tags und Verzweigungen in SVN entfernen, die Sie nicht benötigen.

Wenn Sie dies auf einem Server im selben Netzwerk oder auf demselben Server ausführen, kann dies ebenfalls sehr beschleunigt werden. Auch wenn dieser Prozess aus irgendeinem Grund unterbrochen wird, können Sie ihn mit fortsetzen

_git svn rebase --continue_

In vielen Fällen sind Sie hier fertig. Wenn Ihr SVN-Repo jedoch ein unkonventionelles Layout aufweist und Sie lediglich ein Verzeichnis in SVN haben, das Sie in einen Git-Zweig einfügen möchten, können Sie einige zusätzliche Schritte ausführen.

Am einfachsten ist es, einfach ein neues SVN-Repo auf Ihrem Server zu erstellen, das der Konvention entspricht, und _svn copy_ zu verwenden, um Ihr Verzeichnis in einen Trunk oder eine Verzweigung zu verschieben. Dies ist möglicherweise die einzige Möglichkeit, wenn sich Ihr Verzeichnis ganz im Stammverzeichnis des Repos befindet. Als ich dies das letzte Mal ausprobierte, lehnte _git svn_ einfach das Auschecken ab.

Sie können dies auch mit git tun. Verwenden Sie für _git svn clone_ einfach das Verzeichnis, das Sie in einen Git-Zweig einfügen möchten.

Nach dem Lauf

_git branch --set-upstream master git-svn
git svn rebase
_

Beachten Sie, dass hierfür Git 1.7 oder höher erforderlich ist.

GitHub hat jetzt eine Funktion zum Importieren aus einem SVN-Repository . Ich habe es aber nie ausprobiert.

Ich habe eine Schritt-für-Schritt-Anleitung ( hier ) zum Konvertieren von svn in in git veröffentlicht.

Kurzfassung:

1) Klonen Sie svn von einer bestimmten Revisionsnummer. (Die Versionsnummer muss die älteste sein, die Sie migrieren möchten.)

git svn clone --username=yourSvnUsername -T trunk_subdir -t tags_subdir -b branches_subdir -r aRevisionNumber svn_url gitreponame

2) Abrufen von SVN-Daten. Dieser Schritt benötigt die meiste Zeit.

cd gitreponame
git svn fetch

wiederholen Sie git svn fetch, bis der Vorgang fehlerfrei abgeschlossen ist

3) Hauptzweig aktualisieren lassen

git svn rebase

4) Erstellen Sie lokale Zweige aus SVN-Zweigen, indem Sie Referenzen kopieren

cp .git/refs/remotes/Origin/* .git/refs/heads/

5) Konvertieren Sie SVN-Tags in Git-Tags

git for-each-ref refs/remotes/Origin/tags | sed 's#^.*\([[:xdigit:]]\{40\}\).*refs/remotes/Origin/tags/\(.*\)$#\2 \1#g' | while read p; do git tag -m "tag from svn" $p; done

6) Platzieren Sie ein Repository an einem besseren Ort wie Github

git remotes add newrepo [email protected]:aUser/aProjectName.git
git Push newrepo refs/heads/*
git Push --tags newrepo

Wenn Sie weitere Informationen wünschen, lesen Sie meine Post oder fragen Sie mich.

Wir können git svn clone Befehle wie folgt verwenden.

• svn log -q <SVN_URL> | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors.txt

Der obige Befehl erstellt eine Autorendatei aus SVN-Commits.

• svn log --stop-on-copy <SVN_URL>

Der obige Befehl gibt Ihnen die erste Revisionsnummer, wenn Ihr SVN-Projekt erstellt wurde.

• git svn clone -r<SVN_REV_NO>:HEAD --no-minimize-url --stdlayout --no-metadata --authors-file authors.txt <SVN_URL>

Mit dem obigen Befehl wird das Git-Repository in local erstellt.

Das Problem ist, dass es keine Zweige und Tags nach Push konvertiert. Sie müssen sie manuell ausführen. Zum Beispiel unten für Zweige:

$ git remote add Origin https://github.com/pankaj0323/JDProjects.git
$ git branch -a
* master
  remotes/Origin/MyDevBranch
  remotes/Origin/tags/MyDevBranch-1.0
  remotes/Origin/trunk
$$ git checkout -b MyDevBranch Origin/MyDevBranch
Branch MyDevBranch set up to track remote branch MyDevBranch from Origin.
Switched to a new branch 'MyDevBranch'
$ git branch -a
* MyDevBranch
  master
  remotes/Origin/MyDevBranch
  remotes/Origin/tags/MyDevBranch-1.0
  remotes/Origin/trunk
$

Für Tags:

$git checkout Origin/tags/MyDevBranch-1.0
Note: checking out 'Origin/tags/MyDevBranch-1.0'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 3041d81... Creating a tag
$ git branch -a
* (detached from Origin/tags/MyDevBranch-1.0)
  MyDevBranch
  master
  remotes/Origin/MyDevBranch
  remotes/Origin/tags/MyDevBranch-1.0
  remotes/Origin/trunk
$ git tag -a MyDevBranch-1.0 -m "creating tag"
$git tag
MyDevBranch-1.0
$

Schieben Sie nun den Master, die Zweige und Tags in das Remote-Git-Repository.

$ git Push Origin master MyDevBranch MyDevBranch-1.0
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (14/14), 2.28 KiB | 0 bytes/s, done.
Total 14 (delta 3), reused 0 (delta 0)
To https://github.com/pankaj0323/JDProjects.git
 * [new branch]      master -> master
 * [new branch]      MyDevBranch -> MyDevBranch
 * [new tag]         MyDevBranch-1.0 -> MyDevBranch-1.0
$

Dienstprogramm svn2git

svn2git Dienstprogramm entfernt manuelle Anstrengungen mit Zweigen und Tags.

Installieren Sie es mit dem Befehl Sudo gem install svn2git. Danach führen Sie den folgenden Befehl aus.

• $ svn2git <SVN_URL> --authors authors.txt --revision <SVN_REV_NO>

Jetzt können Sie die Zweige, Tags auflisten und einfach verschieben.

$ git remote add Origin https://github.com/pankaj0323/JDProjects.git
$ git branch -a
  MyDevBranch
* master
  remotes/svn/MyDevBranch
  remotes/svn/trunk
$ git tag
  MyDevBranch-1.0
$ git Push Origin master MyDevBranch MyDevBranch-1.0

Stellen Sie sich vor, Sie haben 20 Verzweigungen und Tags. Svn2git spart Ihnen natürlich viel Zeit und deshalb gefällt es mir besser als native Befehle. Es ist ein netter Wrapper um den nativen Befehl git svn clone.

Ein vollständiges Beispiel finden Sie in meinem Blogeintrag .

TortoiseGit macht das. Siehe diesen Blog-Beitrag: http://jimmykeen.net/articles/03-nov-2012/how-migrate-from-svn-to-git-windows-using-tortoise-clients

Ja, ich weiß, das Antworten mit Links ist nicht großartig, aber es ist eine Lösung, oder?

Für GitLab Benutzer habe ich hier eine Übersicht darüber erstellt, wie ich von SVN migriert bin:

https://Gist.github.com/leftclickben/322b7a3042cbe97ed2af

Schritte zum Migrieren von SVN zu GitLab

Konfiguration

• SVN wird bei svn.domain.com.au gehostet.
• Auf SVN kann über http zugegriffen werden (andere Protokolle sollten funktionieren).
• GitLab wird gehostet bei git.domain.com.au und:
  • Eine Gruppe wird mit dem Namespace dev-team erstellt.
  • Mindestens ein Benutzerkonto wird erstellt, der Gruppe hinzugefügt und verfügt über einen SSH-Schlüssel für das Konto, das für die Migration verwendet wird (Test mit ssh [email protected]).
  • Das Projekt favourite-project wird im Namensraum dev-team erstellt.
• Die Datei users.txt enthält die relevanten Benutzerdetails (ein Benutzer pro Zeile) in der Form username = First Last <[email protected]>, wobei username der in SVN-Protokollen angegebene Benutzername ist. (Siehe den ersten Link im Abschnitt Referenzen für Details, insbesondere die Antwort des Benutzers Casey).

Versionen

• Subversion Version 1.6.17 (r1128011)
• git-Version 1.9.1
• GitLab Version 7.2.1 ff1633f
• Ubuntu-Server 14.04

Befehle

bash
git svn clone --stdlayout --no-metadata -A users.txt 
http://svn.domain.com.au/svn/repository/favourite-project
cd favourite-project
git remote add gitlab [email protected]:dev-team/favourite-project.git
git Push --set-upstream gitlab master

Das ist es! Laden Sie die Projektseite in der GitLab-Weboberfläche neu und Sie sehen alle jetzt aufgelisteten Commits und Dateien.

Anmerkungen

• Wenn es unbekannte Benutzer gibt, wird der Befehl git svn clone gestoppt. In diesem Fall werden die Aktualisierungen von users.txt, cd favourite-project und git svn fetch dort fortgesetzt, wo sie gestoppt wurden.
• Das Standardlayout trunk-tags-branches für das SVN-Repository ist erforderlich.
• Die dem Befehl git svn clone zugewiesene SVN-URL stoppt auf der Ebene unmittelbar über trunk/, tags/ und branches/.
• Der Befehl git svn clone erzeugt eine Menge Ausgaben, einschließlich einiger Warnungen oben; Ich habe die Warnungen ignoriert.

Wenn Sie SourceTree verwenden, können Sie dies direkt aus der App heraus tun. Gehe zu Datei -> Neu/Klonen und mache dann folgendes:

1. Geben Sie die entfernte SVN-URL als "Quellpfad/URL" ein.
2. Geben Sie Ihre Anmeldeinformationen ein, wenn Sie dazu aufgefordert werden.
3. Geben Sie den lokalen Ordner als "Zielpfad" ein.
4. Gib ihm einen Namen.
5. Wählen Sie in den erweiterten Optionen "Git" aus der Dropdown-Liste unter "Lokales Repository des Typs erstellen".
6. Sie können optional eine Revision angeben, von der geklont werden soll.
7. Hit Clone.

Öffnen Sie das Repo in SourceTree und Sie werden sehen, dass Ihre Commit-Nachrichten ebenfalls migriert wurden.

Gehen Sie nun zu Repository -> Repository-Einstellungen und fügen Sie die neuen Remote-Repo-Details hinzu. Löschen Sie die SVN-Fernbedienung, wenn Sie möchten (ich habe dies über die Option "Edit Config File" (Konfigurationsdatei bearbeiten) getan).

Schieben Sie den Code auf das neue Remote-Repo, wenn Sie bereit sind und frei codieren.

Ich kann das nur empfehlen kurze Reihe von Screencasts Ich habe es gerade entdeckt. Der Autor führt Sie durch die grundlegenden Vorgänge und zeigt einige weiterführende Verwendungsmöglichkeiten.

Hier ist ein einfaches Shell-Skript ohne Abhängigkeiten, das ein oder mehrere SVN-Repositorys in Git konvertiert und an GitHub weiterleitet.

https://Gist.github.com/NathanSweet/7327535

In ungefähr 30 Zeilen Skript klont es mit Git-SVN, erstellt eine .gitignore-Datei aus SVN :: ignore-Eigenschaften, verschiebt sie in ein leeres Git-Repository, benennt SVN-Trunk in Master um, konvertiert SVN-Tags in Git-Tags und verschiebt sie zu GitHub unter Beibehaltung der Tags.

Ich habe mir große Mühe gegeben, ein Dutzend SVN-Repositorys von Google Code nach GitHub zu verschieben. Es hat nicht geholfen, dass ich Windows verwendet habe. Ruby war auf meiner alten Debian-Box irgendwie kaputt und es war ein Witz, es unter Windows zum Laufen zu bringen. Andere Lösungen funktionierten nicht mit Cygwin-Pfaden. Selbst wenn etwas funktioniert, konnte ich nicht herausfinden, wie die Tags auf GitHub angezeigt werden sollen (das Geheimnis ist --follow-tags).

Am Ende habe ich zwei kurze und einfache Skripte zusammengeschustert, die oben verlinkt sind, und es funktioniert großartig. Die Lösung muss nicht komplizierter sein!

Abgesehen davon ist der Befehl git-stash ein Glücksfall, wenn Sie versuchen, mit git-svn dcommits zu giten.

Ein typischer Prozess:

1. git repo einrichten
2. arbeiten Sie an verschiedenen Dateien
3. beschließe, einen Teil der Arbeit mit git einzuchecken
4. entscheide dich zu svn-dcommit
5. holen Sie sich den gefürchteten Fehler "Kann mit einem fehlerhaften Index nicht festgeschrieben werden".

Die Lösung (erfordert git 1.5.3+):

git stash; git svn dcommit ; git stash apply

Ich bin auf einem Windows-Rechner und habe einen kleinen Stapel erstellt, um ein SVN-Repo mit Verlauf (aber ohne Verzweigungen) durch einfachen Aufruf auf ein GIT-Repo zu übertragen

transfer.bat http://svn.my.address/svn/myrepo/trunk https://git.my.address/orga/myrepo

Vielleicht kann es jeder benutzen. Es erstellt einen TMP-Ordner, checkt dort das SVN-Repo mit git aus und fügt den neuen Origin hinzu und verschiebt ihn ... und löscht den Ordner erneut.

@echo off 
SET FROM=%1 
SET TO=%2 
SET TMP=tmp_%random%

echo from:  %FROM% 
echo to:    %TO% 
echo tmp:   %TMP%

pause

git svn clone  --no-metadata --authors-file=users.txt %FROM% %TMP%  
cd %TMP% 
git remote add Origin %TO% 
git Push --set-upstream Origin master


cd .. 
echo delete %TMP% ... 
pause

rmdir /s /q %TMP%

Du brauchst noch die users.txt mit deinen User-Mappings wie

User1 = User One <[email protected]>

Ich wollte nur meinen Beitrag zur Git-Community hinzufügen. Ich habe ein einfaches Bash-Skript geschrieben, das den vollständigen Import automatisiert. Im Gegensatz zu anderen Migrationstools basiert dieses Tool auf nativem Git anstelle von jGit. Dieses Tool unterstützt auch Repositorys mit einem großen Revisionsverlauf und/oder großen Blobs. Es ist über Github erhältlich:

https://github.com/onepremise/SGMS

Dieses Skript konvertiert in SVN gespeicherte Projekte mit folgendem Format:

/trunk
  /Project1
  /Project2
/branches
     /Project1
     /Project2
/tags
 /Project1
 /Project2

Dieses Schema ist auch beliebt und wird auch unterstützt:

/Project1
     /trunk
     /branches
     /tags
/Project2
     /trunk
     /branches
     /tags

Jedes Projekt wird anhand des Projektnamens synchronisiert:

Ex: ./migration https://svnurl.com/basepath project1

Wenn Sie das vollständige Repo-Over konvertieren möchten, verwenden Sie die folgende Syntax:

Ex: ./migration https://svnurl.com/basepath .

Es gibt verschiedene Methoden, um dieses Ziel zu erreichen. Ich habe einige von ihnen ausprobiert und festgestellt, dass sie wirklich funktionieren, wenn nur Git und Svn unter Windows installiert sind.

Voraussetzungen:

1. git unter Windows (ich habe dieses verwendet) https://git-scm.com/
2. sVN mit installierten Konsolentools (ich habe Schildkröte SVN verwendet)
3. Dump-Datei Ihres SVN-Repository. svnadmin dump /path/to/repository > repo_name.svn_dump

Schritte zum Erreichen des endgültigen Ziels (Verschieben des gesamten Repositorys mit Verlauf in ein Git, zuerst lokales Git, dann Remote)

1. Erstellen Sie ein leeres Repository (mithilfe von Konsolentools oder tortoiseSVN) im Verzeichnis REPO_NAME_FOLDER cd REPO_NAME_PARENT_FOLDER und fügen Sie dumpfile.dump in REPO_NAME_PARENT_FOLDER ein

2. svnadmin load REPO_NAME_FOLDER < dumpfile.dump Warten Sie auf diesen Vorgang, es kann lange dauern

3. Dieser Befehl ist still, also öffne das zweite Cmd-Fenster: svnserve -d -R --root REPO_NAME_FOLDER Warum nicht einfach file: /// ......? Der nächste Befehl schlägt mit Unable to open ... to URL: fehl, dank der Antwort https://stackoverflow.com/a/6300968/4953065

4. Erstellen Sie einen neuen Ordner SOURCE_GIT_FOLDER

5. cd SOURCE_GIT_FOLDER
6. git svn clone svn: // localhost/Warte auf diesen Vorgang.

Endlich, was haben wir?

Sehen wir uns unser lokales Repository an:

git log

Sehen Sie Ihre vorherigen Verpflichtungen? Wenn ja - okay

Jetzt haben Sie ein voll funktionsfähiges lokales Git-Repository mit Ihren Quellen und der alten SVN-Geschichte. Wenn Sie es nun auf einen Server verschieben möchten, verwenden Sie die folgenden Befehle:

git remote add Origin https://fullurlpathtoyourrepo/reponame.git
git Push -u Origin --all # pushes up the repo and its refs for the first time
git Push -u Origin --tags # pushes up any tags

In meinem Fall brauche ich den Befehl tags nicht, da mein Repo keine Tags hat.

Viel Glück!

GitHub hat einen Importeur. Sobald Sie das Repository erstellt haben, können Sie es über seine URL aus einem vorhandenen Repository importieren. Sie werden gegebenenfalls nach Ihren Anmeldeinformationen gefragt und von dort weitergeleitet.

Während des Betriebs werden Autoren gefunden und Sie können sie einfach Benutzern auf GitHub zuordnen.

Ich habe es jetzt für ein paar Repositories verwendet, und es ist ziemlich genau und auch viel schneller! Es dauerte 10 Minuten für ein Repository mit ~ 4000 Commits, und nachdem es meinen Freund vier Tage gedauert hatte!

Git effektiv mit Subversion verwenden ist eine sanfte Einführung in git-svn. Mit git-svn ist dies für vorhandene SVN-Repositorys ganz einfach. Wenn Sie ein neues Repository starten, ist es sehr viel einfacher, zuerst ein leeres SVN-Repository zu erstellen und dann mit git-svn zu importieren, als in die entgegengesetzte Richtung. Das Erstellen eines neuen Git-Repositorys und der Import in SVN können durchgeführt werden. Dies ist jedoch etwas schmerzhaft, insbesondere wenn Sie Git noch nicht kennen und hoffen, den Commit-Verlauf beizubehalten.

Einige Antworten beziehen sich hier auf https://github.com/nirvdrum/svn2git , bei großen Repositorys kann dies jedoch langsam sein. Ich habe versucht, https://github.com/svn-all-fast-export/svn2git zu verwenden, ein Tool mit genau demselben Namen, das jedoch zur Migration von KDE von SVN nach Git verwendet wurde.

Etwas mehr Arbeit, um es einzurichten, aber als die Konvertierung für mich abgeschlossen war, dauerte es Minuten, in denen das andere Skript Stunden verbrachte.

Laden Sie das Installationsprogramm Ruby für Windows herunter und installieren Sie die neueste Version damit. Fügen Sie Ihrem Pfad Ruby ausführbare Dateien hinzu.

• Installieren Sie svn2git
• Startmenü -> Alle Programme -> Ruby -> Starten Sie eine Eingabeaufforderung mit Ruby

• Geben Sie dann "gem install svn2git" ein und geben Sie ein

  Subversion-Repository migrieren

• Öffnen Sie eine Ruby Eingabeaufforderung und wechseln Sie in das Verzeichnis, in das die Dateien migriert werden sollen

  Dann svn2git http: // [domain name]/svn/[repository root]

• Je nach Größe des Projektcodes kann es einige Stunden dauern, bis das Projekt auf Git migriert ist.

• Dieser Hauptschritt hilft beim Erstellen der Git-Repository-Struktur, wie unten erwähnt.

  SVN-Trunk (/ Project_components) -> Git-Master-SVN-Verzweigungen (/ Project_components) -> Git-Verzweigungen SVN-Tags (/ Project_components) -> Git-Tags

Erstellen Sie das Remote-Repository und übertragen Sie die Änderungen.

Ich habe das folgende Skript verwendet, um eine Textdatei zu lesen, die eine Liste aller meiner SVN-Repositorys enthält, und sie in Git zu konvertieren. Später verwende ich git clone --bare, um sie in ein nacktes Git-Repository zu konvertieren:

#!/bin/bash
file="list.txt"
while IFS= read -r repo_name
do
 printf '%s\n' "$repo_name"
 Sudo git svn clone --shared --preserve-empty-dirs --authors-file=users.txt file:///programs/svn/$repo_name
 Sudo git clone --bare /programs/git/$repo_name $repo_name.git
 Sudo chown -R www-data:www-data $repo_name.git
 Sudo rm -rf $repo_name
done <"$file"

list.txt hat das Format:

repo1_name
repo2_name

Und users.txt hat das Format:

(no author) = Prince Rogers <[email protected]>

www-data ist der Benutzer des Apache-Webservers. Zum Pushen von Änderungen über HTTP ist eine Berechtigung erforderlich.

Konvertieren des SVN-Submoduls/Ordners 'MyModule' in Git mit Verlauf ohne Tags oder Verzweigungen.

• git svn clone --no-metadata --trunk = SomeFolder1/SomeFolder2/SomeFolder3/MyModule http: //svnhost: port/repo_root_folder/MyModule_temp -A C:\cheetah\svn\artists-transform.txt
• git-Klon MyModule_temp MyModule
• cd MyModule
• git Flow Init
• git remote set-url Origin https://[email protected]/stash/scm/xyzxyz/MyModule.git
• git Push -u Origin Master
• git Push -u Origin entwickeln

Verwenden Sie die obigen Kommentare nach Schritt 1, um die SVN-Ignorierliste beizubehalten