Ich habe das Git-Handbuch, die FAQ, den Git-SVN-Crashkurs usw. gelesen und alle erklären dies und das, aber nirgendwo finden Sie eine einfache Anleitung wie:

SVN-Repository in: svn://myserver/path/to/svn/repos

Git-Repository in: git://myserver/path/to/git/repos

git-do-the-magic-svn-import-with-history \
svn://myserver/path/to/svn/repos \
git://myserver/path/to/git/repos

Ich erwarte nicht, dass es so einfach ist, und ich erwarte nicht, dass es ein einzelner Befehl ist. Aber ich erwarte, dass es nicht versucht, etwas zu erklären - nur um zu sagen, welche Schritte in diesem Beispiel zu unternehmen sind.

Magie:

$ git svn clone http://svn/repo/here/trunk

Git und SVN arbeiten sehr unterschiedlich. Sie müssen Git lernen, und wenn Sie Änderungen von SVN Upstream verfolgen möchten, müssen Sie lernen git-svn. Die git-svn Hauptseite enthält einen guten Beispielabschnitt :

$ git svn --help

Erstellen Sie eine Benutzerdatei (dh users.txt) für die Zuordnung von SVN-Benutzern zu Git:

user1 = First Last Name <email@address.com>
user2 = First Last Name <email@address.com>
...

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 gestoppt, 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-tmpund beginnt mit dem Abrufen des SVN-Repositorys. Beachten Sie, dass das Flag "--stdlayout" impliziert, dass Sie das gemeinsame SVN-Layout "trunk /, branch /, tags /" haben. Wenn Ihr Layout unterscheidet, werden vertraut mit --tags, --branches, --trunkOptionen (im Allgemeinen git svn help).

Alle gängigen Protokolle sind erlaubt: svn://, http://, https://. Die URL sollte auf das Basis-Repository abzielen, z. B. http://svn.mycompany.com/myrepo/repository . Die URL-Zeichenfolge darf nicht enthalten /trunk, /tagoder /branches.

Beachten Sie, dass es nach dem Ausführen dieses Befehls sehr oft so aussieht, als ob der Vorgang "hängen bleibt / einfriert", und es ist ganz normal, dass er nach der Initialisierung des neuen Repositorys für eine lange Zeit hängen bleiben kann. Schließlich werden dann Protokollmeldungen angezeigt, die darauf hinweisen, dass die Migration erfolgt.

Beachten Sie auch, dass --no-metadataGit , wenn Sie das Flag weglassen , Informationen über die entsprechende SVN-Revision an die Festschreibungsnachricht anfügt (dh git-svn-id: svn://svn.mycompany.com/myrepo/<branchname/trunk>@<RevisionNumber> <Repository UUID>)

Wenn kein Benutzername gefunden wird, aktualisieren Sie Ihre users.txtDatei 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 den SVN trunkin einen neuen Zweig aus. Alle anderen Zweige werden als Fernbedienungen eingerichtet. Sie können die anderen SVN-Zweige anzeigen mit:

git branch -r

Wenn Sie andere Remote-Zweige in Ihrem Repository behalten möchten, möchten Sie für jeden manuell einen lokalen Zweig erstellen. (Stamm / 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 einen lokalen Zweig erstellen, ein Tag erstellen und den Zweig 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

Migrieren Sie Ihr Subversion-Repository sauber in ein Git-Repository . Zuerst müssen Sie eine Datei erstellen, die Ihre Subversion-Commit-Autorennamen Git-Commitern zuordnet, z. B ~/authors.txt.:

jmaddox = Jon Maddox <jon@gmail.com>
bigpappa = Brian Biggs <bigpappa@gmail.com>

Anschließend 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-svnMacPorts durch Installation herunterladen git-core +svn.

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 alle:

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

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

Ich empfehle, sich mit Git vertraut zu machen, bevor Sie versuchen, git-svn ständig zu verwenden, dh 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 aufgeführt:

Initialisieren Sie 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 seitdem holen:

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 auf GitHub ?):

git remote add origin git@github.com: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_branchTool auszuprobieren, das Ihnen beim Umgang mit entfernten Zweigen hilft:

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 zu 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 bisher funktioniert es sehr gut.

Um mit SubGit von Subversion zu 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.

Wenn Ihr Subversion-Repository mehrere Projekte enthält, werden mehrere Git-Repositorys im Verzeichnis svn_repos / git erstellt. Gehen Sie wie folgt vor, um die Übersetzung vor dem Ausführen anzupassen:

$ 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 auf reines Git (nicht git-svn) migrieren und es verwenden, während Sie Subversion so lange beibehalten , wie Sie es benötigen (z. B. für Ihre bereits konfigurierten Build-Tools).

Hoffe das hilft!

Siehe die offizielle git-svn-Manpage . Schauen Sie insbesondere unter "Grundlegende Beispiele" nach:

Verfolgung und Beitrag zu 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 ein Git-Repository, das mit dem ersten Befehl erstellt wurde.

subgit import  directory/path/Local.git.Repo

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

Hier ist mein Weg.

Meine Lösung sieht aus wie:

• Migrieren Sie SVN in ein Git-Repository
• Aktualisieren Sie das Git-Repository kurz vor dem Wechsel des Teams zu .

Die Migration nimmt viel Zeit für ein großes SVN-Repository in Anspruch.
Die Aktualisierung der abgeschlossenen Migration dauert jedoch nur wenige Sekunden.

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

SCHRITTE

1. Laden Sie SubGit herunter

2. Bereiten Sie die Migrations- und Aktualisierungsbefehle vor.

Nehmen wir an, wir machen das für Windows (es ist trivial, auf Linux zu portieren).
In einer Installation des SubGit ist Verzeichnis (subgit-2.XX \ ist), erstellen Sie 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 ermöglicht das Anzeigen von Fehlern beim Start und lässt eine Shell nach Abschluss des SubGit geöffnet.

Sie können hier zusätzliche Parameter hinzufügen , die git-svn ähneln . 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 / Zweige / Tags) und wir hatten keine Probleme mit der "Autorenzuordnung". Also mache ich nichts mehr.

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

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 ( Ctrl+ C) und durch Ausführen des nächsten Aktualisierungsbefehls / der nächsten Aktualisierungsdatei wiederhergestellt werden.
Ich rate nicht, dies für große Repositories zu tun. Ich habe "Java + Windows-Ausnahme" Nicht genügend Speicher "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.

Warnung! Berühren Sie nicht Ihr nacktes Repository (z. B. Erstellung 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. Für ein großes Repository wird es eine lange Zeit dauern. 30 Stunden für mein bescheidenes Repository.

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

Es gibt noch eine nützliche Aufgabe.

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

Ist es dein Fall? Fahren wir fort.

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 Chunks senden. tödlich: Das entfernte Ende legte unerwartet auf

Lass uns losrennen:

git config --global http.postBuffer 1073741824

524288000 - 500 MB 1073741824 - 1 GB usw.

Beheben Sie die Probleme mit Ihrem lokalen Zertifikat . Wenn Ihr Git-Server ein defektes Zertifikat verwendet.

Ich habe Zertifikate deaktiviert .

Außerdem kann es auf Ihrem Git-Server zu Einschränkungen bei der Anforderungsmenge kommen, die korrigiert werden müssen .

3. Übertragen Sie die gesamte Migration in das Remote-Git-Repository des Teams.

Führen Sie mit einem lokalen Git:

git push origin --mirror

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

Wenn Sie Folgendes erhalten: Fehler: Git kann nicht erzeugt werden: Keine solche Datei oder kein solches Verzeichnis ... Für mich löst die vollständige Neuerstellung meines Repositorys diesen Fehler (30 Stunden). Sie können die nächsten Befehle ausprobieren

git push origin --all
git push origin --tags

Oder versuchen Sie, Git neu zu installieren ( für mich nutzlos ). Oder Sie können aus allen Tags Zweige erstellen und diese verschieben. Oder oder oder oder ...

Reposurgeon

In komplizierten Fällen ist der Reposurgeon von Eric S. Raymond das Werkzeug der Wahl. Zusätzlich zu SVN unterstützt es viele andere Versionskontrollsysteme über das fast-exportFormat und auch CVS . 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- svn:ignoreEigenschaften in .gitignoreDateien), selbst bei schwierigen Repository-Layouts mit einer langen Geschichte. In vielen Fällen sind andere Tools möglicherweise einfacher zu verwenden.

Bevor Sie sich mit der Dokumentation der reposurgeonBefehlszeile befassen , lesen Sie unbedingt die ausgezeichnete DVCS-Migrationsanleitung, in der der Konvertierungsprozess Schritt für Schritt beschrieben wird.

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 Ihre 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. Rufen Sie eine Liste aller Subversion-Committer ab

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 den SVN-Benutzernamen sowohl im Autoren- als auch im E-Mail-Feld auf. Mit ein wenig Arbeit können Sie jedoch 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 diesen Befehl im Stammverzeichnis Ihrer lokalen Subversion-Prüfung 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 herausgerissen, doppelte Benutzernamen entfernt, die Benutzernamen sortiert und in einer Datei "autors-transform.txt" abgelegt. Bearbeiten Sie nun jede Zeile in der Datei. Konvertieren Sie beispielsweise:

jwilkins = jwilkins <jwilkins>

das sehr gut finden:

jwilkins = John Albin Wilkins <johnalbin@example.com>

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 (unter Verwendung der in Schritt 1 erstellten Datei autors-transform.txt) durchgeführt und das Git-Repository im Ordner "~ / temp" in Ihrem Home-Verzeichnis abgelegt.

3. Konvertieren Sie svn: ignorieren Sie die Eigenschaften in .gitignore

Wenn Ihr svn-Repo die Eigenschaften svn: ignore verwendet hat, können Sie diese einfach in eine .gitignore-Datei konvertieren, indem Sie:

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

4. Schieben Sie das Repository in ein Bare-Git-Repository

Erstellen Sie zunächst ein nacktes Repository und stellen Sie sicher, dass der Standardzweig mit dem Zweigstellennamen "trunk" von svn ü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 nackte 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. Benennen Sie den Zweig "Amtsleitung" in "Master" um

Ihr Hauptentwicklungszweig heißt "Trunk" und entspricht dem Namen in Subversion. Sie möchten es in Git's Standard-Master-Zweig umbenennen, indem Sie:

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

6. Bereinigen Sie Zweige und Tags

git-svn macht alle Subversions-Tags in Git zu sehr kurzen Zweigen der Form "tags / name". Sie möchten alle diese Zweige in tatsächliche Git-Tags konvertieren, indem Sie:

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 mach dir keine Sorgen; Ihre Unix-Shell bietet eine> sekundäre Eingabeaufforderung für den extra langen Befehl, der mit git for-each-ref beginnt.

GitHub verfügt jetzt über eine Funktion zum Importieren aus einem SVN-Repository . Ich habe es aber nie versucht.

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 Verzeichnislayout für Trunk / Branches / Tags verwenden (SVN unternimmt absolut nichts, um diese Art von Layout durchzusetzen).

Verwenden Sie zuerst dieses Bash-Skript, um Ihr SVN-Repo nach den verschiedenen Personen zu durchsuchen, die dazu 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 <USER@DOMAIN>";
done

Verwenden Sie diese authorsOption , um eine Datei zu erstellen , in der Sie SVN-Benutzernamen Benutzernamen und E-Mails zuordnen, die von Ihren Entwicklern mithilfe von git configEigenschaften user.nameund festgelegt wurden user.email(beachten Sie, dass für einen Dienst wie GitHub nur eine passende E-Mail-Adresse ausreicht).

Dann hat git svnKlon mit der SVN - Repository zu einem Git Repository, es geht um die Zuordnung zu sagen:

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 einzelnen Zweig einzeln überprüft. (Beachten Sie, dass Tags in SVN nur echte Zweige sind, sodass sie als solche in Git enden.) Sie können dies beschleunigen, indem Sie alte Tags und Zweige in SVN entfernen, die Sie nicht benötigen.

Das Ausführen auf einem Server im selben Netzwerk oder auf demselben Server kann dies ebenfalls erheblich beschleunigen. 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 hat, in dem Sie einfach 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 copyIhr Verzeichnis in einen Trunk oder einen Zweig zu stellen. Dies ist möglicherweise der einzige Weg, wenn sich Ihr Verzeichnis vollständig im Stammverzeichnis des Repos befindet, als ich dies das letzte Mal versucht habegit svn weigerte einfach, eine Kaufabwicklung durchzuführen.

Sie können dies auch mit git tun. Zumgit svn clone einfach das Verzeichnis verwenden möchten Sie in einem git Zweig setzen.

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.

Ich habe eine Schritt-für-Schritt-Anleitung ( hier ) zum Konvertieren von SVN in Git veröffentlicht, einschließlich der Konvertierung von SVN-Tags in Git-Tags und SVN-Zweigen in Git-Zweige.

Kurzfassung:

1) Klonen Sie SVN von einer bestimmten Versionsnummer. (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 dauert am meisten.

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) konvertiere 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) Stellen Sie ein Repository an einem besseren Ort wie Github auf

git remotes add newrepo git@github.com:aUser/aProjectName.git
git push newrepo refs/heads/*
git push --tags newrepo

Wenn Sie weitere Informationen wünschen, lesen Sie meinen Beitrag oder fragen Sie mich.

Wir können die folgenden git svn cloneBefehle 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>

Der obige Befehl erstellt das Git-Repository in local.

Das Problem ist, dass Zweige und Tags nicht in Push konvertiert werden. 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 Master, 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

Das Dienstprogramm svn2git entfernt manuelle Anstrengungen mit Zweigen und Tags.

Installieren Sie es mit dem Befehl sudo gem install svn2git. Führen Sie danach den folgenden Befehl aus.

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

Jetzt können Sie die Zweige und 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 Zweige und Tags. Mit svn2git sparen Sie natürlich viel Zeit. Deshalb gefällt es mir besser als mit nativen Befehlen. Es ist eine nette Hülle um native git svn cloneBefehle.

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ß, dass das Antworten mit Links nicht großartig ist, aber es ist eine Lösung, oder?

Ich kann diese kurze Serie von Screencasts, die ich gerade entdeckt habe, nur empfehlen . Der Autor führt Sie durch die grundlegenden Vorgänge und zeigt einige fortgeschrittenere Verwendungen.

Wenn Sie SourceTree verwenden, können Sie dies direkt über die App tun. Gehe zu Datei -> Neu / Klonen und gehe dann wie folgt vor:

1. Geben Sie die Remote-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 vom Typ erstellen".
6. Sie können optional eine Revision angeben, aus der geklont werden soll.
7. Hit Clone.

Öffnen Sie das Repo in SourceTree und Sie werden sehen, dass auch Ihre Commit-Nachrichten 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 dies wünschen (ich habe dies über die Option "Konfigurationsdatei bearbeiten" getan).

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

Für GitLab- Benutzer habe ich hier einen Überblick darüber gegeben, wie ich von SVN migriert bin:

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

Schritte zur Migration von SVN zu GitLab

Installieren

• SVN wird gehostet bei svn.domain.com.au.
• Auf SVN kann über zugegriffen werden http(andere Protokolle sollten funktionieren).
• GitLab wird gehostet bei git.domain.com.auund:
  • Mit dem Namespace wird eine Gruppe erstellt dev-team.
  • 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 git@git.domain.com.au).
  • Das Projekt favourite-projectwird im dev-teamNamespace erstellt.
• Die Datei users.txtenthält die relevanten Benutzerdetails (ein Benutzer pro Zeile) des Formulars username = First Last <address@domain.com.au>, wobei usernameder in SVN-Protokollen angegebene Benutzername angegeben ist. (Siehe ersten Link im Abschnitt Referenzen für Details, insbesondere Antwort von Benutzer 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 git@git.domain.com.au:dev-team/favourite-project.git
git push --set-upstream gitlab master

Das ist es! Laden Sie die Projektseite erneut in die GitLab-Web-Benutzeroberfläche und Sie sehen alle Commits und Dateien, die jetzt aufgelistet sind.

Anmerkungen

• Wenn es unbekannte Benutzer sind, der git svn clonewird Befehl stoppen, wobei in diesem Fall, zu aktualisieren users.txt, cd favourite-projectund git svn fetchwird auch weiterhin von dort gestoppt.
• Das Standard trunk- tags- branchesLayout für SVN - Repository erforderlich.
• Die SVN - URL zu dem gegebenen git svn cloneBefehl stoppt auf der Ebene unmittelbar über trunk/, tags/und branches/.
• Der git svn cloneBefehl erzeugt eine Menge Ausgabe, einschließlich einiger Warnungen oben; Ich habe die Warnungen ignoriert.

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

Ein typischer Prozess:

1. git repo einrichten
2. Arbeiten Sie an verschiedenen Dateien
3. Entscheide dich, einen Teil der Arbeit mit git einzuchecken
4. entscheiden svn-dcommit
5. Holen Sie sich den gefürchteten Fehler "Kann nicht mit einem schmutzigen Index festschreiben".

Die Lösung (erfordert Git 1.5.3+):

git stash; git svn dcommit ; git stash apply

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

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

In ungefähr 30 Skriptzeilen wird es: Klonen mit Git-SVN, Erstellen einer Gitignore-Datei aus SVN :: Ignore-Eigenschaften, Verschieben in ein Bare-Git-Repository, Umbenennen von SVN-Trunk in Master, Konvertieren von SVN-Tags in Git-Tags und Verschieben in GitHub unter Beibehaltung der Tags.

Ich habe mir große Mühe gegeben, ein Dutzend SVN-Repositorys von Google Code auf 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, sie unter Windows zum Laufen zu bringen. Andere Lösungen funktionierten nicht mit Cygwin-Pfaden. Selbst wenn etwas funktioniert hat, konnte ich nicht herausfinden, wie die Tags auf GitHub angezeigt werden können (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!

Ich bin auf einem Windows-Computer und habe einen kleinen Stapel erstellt, um ein SVN-Repo mit Verlauf (aber ohne Verzweigungen) durch einfaches Aufrufen 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 Ursprung hinzu und schiebt 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%

Sie benötigen weiterhin die Datei users.txt mit Ihren Benutzerzuordnungen wie

User1 = User One <u.1@xxx.com>

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 im folgenden Format:

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

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

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

Jedes Projekt wird nach Projektnamen synchronisiert:

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

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

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

Die effektive Verwendung von Git mit Subversion ist eine sanfte Einführung in git-svn. Für vorhandene SVN-Repositorys macht git-svn dies sehr einfach. Wenn Sie ein neues Repository starten, ist es wesentlich 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 das Importieren in SVN ist möglich, aber es ist etwas schmerzhaft, insbesondere wenn Sie neu bei Git sind und hoffen, den Commit-Verlauf beizubehalten.

Laden Sie das Ruby-Installationsprogramm für Windows herunter und installieren Sie die neueste Version damit. Fügen Sie Ihrem Pfad ausführbare Ruby-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: // [Domänenname ] / svn / [Repository-Stamm]

• Die Migration des Projekts zu Git kann abhängig von der Größe des Projektcodes einige Stunden dauern.

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

  SVN (/ Project_components) Trunk -> Git Master SVN (/ Project_components) Zweige -> Git verzweigt SVN (/ Project_components) Tags -> Git Tags

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

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

Während der Ausführung 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 danach dauerte es vier Tage für meinen Freund!

Einige Antworten finden Sie hier unter 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 stattdessen ist ein Tool mit genau demselben Namen, das jedoch zum Migrieren von KDE von SVN nach Git verwendet wurde.

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

Es gibt verschiedene Methoden, um dieses Ziel zu erreichen. Ich habe einige davon ausprobiert und festgestellt, dass es wirklich funktioniert, 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 tortoise svn verwendet)
3. Dump-Datei Ihres SVN-Repositorys. svnadmin dump /path/to/repository > repo_name.svn_dump

Schritte zum Erreichen des endgültigen Ziels (Verschieben Sie das gesamte Repository mit Verlauf in einen Git, zuerst einen lokalen Git, dann einen Remote-Git).

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

2. svnadmin load REPO_NAME_FOLDER < dumpfile.dump Warten Sie auf diesen Vorgang, er kann lang sein

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

4. Erstellen Sie einen neuen Ordner SOURCE_GIT_FOLDER

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

Was haben wir endlich?

Überprüfen wir unser lokales Repository:

git log

Sehen Sie Ihre vorherigen Commits? Wenn ja - okay

Jetzt haben Sie ein voll funktionsfähiges lokales Git-Repository mit Ihren Quellen und dem alten SVN-Verlauf. Wenn Sie es jetzt 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 keinen Befehl tags, weil mein Repo keine Tags hat.

Viel Glück!

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: \ \ svn \ -transform.txt
• Git-Klon MyModule_temp MyModule
• cd MyModule
• Git Flow Init
• Git Remote Set-URL Ursprung https: //userid@stashhost/stash/scm/xyzxyz/MyModule.git
• Git Push -u Origin Master
• Git Push -u Ursprung entwickeln

Um die svn-Ignorierliste beizubehalten, verwenden Sie die obigen Kommentare nach Schritt 1