• Link zu Xing
  • Link zu LinkedIn
  • Link zu X
  • Link zu Rss dieser Seite
  • Link zu GitHub
  • Newsletter
  • Kontaktieren Sie mich
Frank W. Rahn
  • Meine BlogbeiträgeZeigt meinen Blog an
  • RessourcenZeigt Ihnen eine Auswahl von Ressourcen
    • Franks aktueller IT-Werkzeugkasten
      • Diese Werkzeuge setze ich zur Zeit ein
    • Meine Präsentationen
      • Zeigt Ihnen meine Präsentationen
    • Weblinks
      • Meine Linksammlung
    • Buchtipps
      • Eine Liste von mir empfohlener Literatur
    • XML-Namespace
      • Zeigt meinem XML-Namespace
  • Franks aktueller IT-WerkzeugkastenDiese Werkzeuge setze ich zur Zeit ein
  • Meine PräsentationenZeigt Ihnen meine Präsentationen
  • WeblinksMeine Linksammlung
  • BuchtippsEine Liste von mir empfohlener Literatur
  • XML-NamespaceZeigt meinem XML-Namespace
  • Über mich …Die persönlichen Informationen über den Softwarearchitekt Frank Rahn
  • Click to open the search input field Click to open the search input field Suche
  • Menü Menü
Howto

Wie Du ein Subversion Repository (SVN) nach Git konvertierst

In diesem Howto beschreibe ich, wie ein existierendes Projekt aus einem Apache Subversion (SVN) Repository in ein Git Repository konvertiert werden kann.

Diesen kann mit Hilfe der bidirektionalen Subversion Brücke git-svn von Git erreicht werden.

Dieses führe ich mit dem Projekt test-spring-simple aus dem Beitrag Spring an einem einfachem Beispiel der Tutorial Serie Einführung in das Spring Framework vor.

Die folgenden Schritte sind notwendig: [verstecken]

  1. Die Installation der bidirektionalen Subversion Brücke git-svn
  2. Die Vorbereitung der Benutzerkennungen
  3. Das Initialisieren des lokalen Repositories
  4. Das Konvertieren der Eigenschaft svn:ignore nach .gitignore
  5. Das Konvertieren der SVN-Tag-Branches in richtige Git-Tags
  6. Das Entfernen von SVN-Branches mit einer Revisionsnummer im Namen
  7. Das Konvertieren der SVN-Branches in lokale Branches
  8. Das Hochladen des Repositories nach GitHub
  9. Die Literaturempfehlungen

Einige Informationen zu Git habe ich im Kapitel Wissenswertes zu Git des Beitrag Git mit GitHub schon einmal beschrieben.

Die Installation der bidirektionalen Subversion Brücke git-svn

Die bidirektionale Unterstützung von Subversion muss für Git gesondert installiert werden.

$ sudo apt-get update
$ sudo apt-get install git-svn
$

Die Vorbereitung der Benutzerkennungen

Dazu muss die Datei authors.txt erstellt werden. In dieser Datei werden die abgekürzten Namen der Subversion Benutzer auf den kompletten Namen der Git Benutzer zugeordnet.

Dadurch werden die Benutzer in der Historie richtig im Git-Style (Name des Benutzers und Email) angezeigt.

$ cat authors.txt 
frank = Frank W. Rahn <...@frank-rahn.de>
$

Zusätzlich sollte noch zwei Einträge für Commits ohne Namen (no author) hinzugefügt werden. Leider benötigt Subversion die Eigenschaft svn:author nicht zwingend. Unterumständen kann dieser Name auch noch in der deutschen Übersetzung vorkommen.

$ svn log -r 4711
-------------------------------------------------------
r4711 | (no author) | (no date) | 1 line
-------------------------------------------------------
$ 
$ cat authors.txt 
frank = Frank W. Rahn <...@frank-rahn.de>
(no author) = Frank W. Rahn <...@frank-rahn.de>
(kein Autor) = Frank W. Rahn <...@frank-rahn.de>
$

Die Datei authors.txt kann auch mit Hilfe des folgenden Scripts direkt aus Subversion erstellt werden.

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

Danach muss die Datei noch bearbeitet werden. Es müssen die korrekten E-Mail-Adressen und ggfs. die Namen der Committer ersetzt werden.

Das Initialisieren des lokalen Repositories

Zunächst muss ein lokales Git Repository angelegt und initialisiert werden.

Die erste Alternativen legt ein Verzeichnis an, initialisiert es und holt die Daten aus dem Subversion Repository.

$ mkdir test-spring-simple
$ cd test-spring-simple
$
$ git svn init -s --no-metadata svn://nll001/share/Repository/presentation/test-spring-simple
Initialized empty Git repository in /home/frank/test-spring-simple/.git/
Using higher level of URL: svn://nll001/share/Repository/presentation/test-spring-simple => svn://nll001/share/Repository
$ 
$ git svn fetch -A ../authors.txt
W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.
This may take a while on large repositories
...
$

Die zweite Alternative erledigt alles in einem Schritt.

$ git svn clone -s -A authors.txt --no-metadata svn://nll001/share/Repository/presentation/test-spring-simple
Initialized empty Git repository in /home/frank/test-spring-simple/.git/
Using higher level of URL: svn://nll001/share/Repository/presentation/test-spring-simple => svn://nll001/share/Repository
W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.
This may take a while on large repositories
...
$

Mit der Option -rRevision:HEAD kann die SVN-Revision angegeben werden, ab der die Daten aus dem SVN Repository ausgelesen werden. Dadurch kann das neue Repository entsprechend verkleinert werden.

$ git svn clone -s -r4711:HEAD -A authors.txt --no-metadata svn://nll001/share/Repository/presentation/test-spring-simple
...
$

Das Konvertieren der Eigenschaft svn:ignore nach .gitignore

In diesem Schritt wird die SVN-Eigenschaft svn:ignore in die Datei .gitignore konvertiert.

$ git svn show-ignore > .gitignore
$ git add .gitignore
$ git commit -m "Convert svn:ignore properties to .gitignore."
$

Das Konvertieren der SVN-Tag-Branches in richtige Git-Tags

Die Tags aus Subversion wurden beim Importieren nach Git in Branches tags/<name> umgewandelt.

$ git branch -r
  b1.0
  tags/2.0.1
  tags/v1.0
  tags/v1.0.1
  tags/v1.0.2
  tags/v2.0
  tags/v2.0.1
  tags/v2.0.2
  tags/v2.0.3
  trunk
$

Der Branch tags/2.0.1 wird gelöscht, da er mit dem Branch tags/v2.0.1 identisch ist.

$ git branch -r -d tags/2.0.1 
Deleted remote branch tags/2.0.1 (was c29f62b).
$

Nun werden die Tags mit den folgenden zwei Befehle konvertiert.

$ git tag <name> tags/<name>
$ git branch -r -d tags/<name>
$

Im folgenden Beispiel werden die beiden Tags v1.0 und v1.0.1 konvertiert.

$ git tag v1.0 tags/v1.0
$ git branch -r -d tags/v1.0
Deleted remote branch tags/v1.0 (was 9899838).
$ 
$ git tag v1.0.1 tags/v1.0.1
$ git branch -r -d tags/v1.0.1
Deleted remote branch tags/v1.0.1 (was 16d40ea).
$

Für die Konvertierung aller Tags in einem Schritt kann folgende Befehlskette verwendet werden.

$ git for-each-ref --format='%(refname)' refs/heads/tags |
> cut -d / -f 4 |
> while read ref
> do
> git tag -a "$ref" -m "Convert "$ref" to a proper git tag." "refs/heads/tags/$ref";
> git branch -D "tags/$ref";
> done
$

Nach dem Konvertieren aller Tags stellt sich folgendes Bild dar.

$ git branch -r
  b1.0
  trunk
$ git branch -a
* master
  remotes/b1.0
  remotes/trunk
$ git tag 
v1.0
v1.0.1
v1.0.2
v2.0
v2.0.1
v2.0.2
v2.0.3
$

Das Entfernen von SVN-Branches mit einer Revisionsnummer im Namen

Manchmal entstehen durch die Konvertierung mit der Subversion Brücke git-svn Branches in der Form Name@Revision.

Mit dieser Befehlskette können diese Branche entfernt werden.

$ git for-each-ref --format='%(refname)' refs/heads |
> grep '@[0-9][0-9]*' |
> cut -d / -f 3- | 
> while read ref 
> do   
> git branch -D "$ref";
> done
$

Das Konvertieren der SVN-Branches in lokale Branches

Zunächst wird der Branch trunk gelöscht, da er im Branch master enthalten ist.

$ git branch -r -d trunk
Deleted remote branch trunk (was 2f5bfb7).
$ 
$ git branch -a
* master
  remotes/b1.0
$

Der verbleibende entfernte Branch b1.0 muss nun noch als Upstream gekennzeichnet und danach gelöscht werden. Der Branch wird gelöscht, da er noch eine Verbindung zum SVN darstellt und diese gekappt werden soll. Im Repository bleiben die Metadaten durch das Löschen unverändert.

Auch hier bieten sich zwei Alternativen an.

$ git checkout -t -b b1.0 b1.0
Branch b1.0 set up to track local ref refs/remotes/b1.0.
Switched to a new branch 'b1.0'
$ 
$ git branch -a
* b1.0
  master
  remotes/b1.0
$ 
$ git branch -r -d b1.0
Deleted remote branch b1.0 (was cce8e83).
$ 
$ git checkout master
Switched to branch 'master'
$ git branch -a
  b1.0
* master
$
$ git branch --track b1.0 b1.0
Branch b1.0 set up to track local ref refs/remotes/b1.0.
$ 
$ git branch -r -d b1.0
Deleted remote branch b1.0 (was cce8e83).
$ 
$ git branch -a
  b1.0
* master
$

Das Hochladen des Repositories nach GitHub

Um ein Repository bei GitHub zu erzeugen, siehe im Beitrag Git mit GitHub. Dabei sollte das Repository nicht mit einer README.md oder .gitignore initialisiert werden, da dieses die Historie des Repositories verändert. Dieses sollte in einem weiteren Schritt nachgeholt werden.

$ git remote add origin git@github.com:frank-rahn/test-spring-simple.git
$ 
$ git push -u origin master b1.0
Enter passphrase for key '/home/frank/.ssh/id_rsa': 
Counting objects: 164, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (128/128), done.
Writing objects: 100% (164/164), 18.99 KiB, done.
Total 164 (delta 54), reused 0 (delta 0)
To git@github.com:frank-rahn/test-spring-simple.git
 * [new branch]      master -> master
 * [new branch]      b1.0 -> b1.0
Branch master set up to track remote branch master from origin.
Branch b1.0 set up to track remote branch b1.0 from origin.
$ 
$ git push --tags
Enter passphrase for key '/home/frank/.ssh/id_rsa': 
Counting objects: 103, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (41/41), done.
Writing objects: 100% (53/53), 4.88 KiB, done.
Total 53 (delta 20), reused 0 (delta 0)
To git@github.com:frank-rahn/test-spring-simple.git
 * [new tag]         v1.0 -> v1.0
 * [new tag]         v1.0.1 -> v1.0.1
 * [new tag]         v1.0.2 -> v1.0.2
 * [new tag]         v2.0 -> v2.0
 * [new tag]         v2.0.1 -> v2.0.1
 * [new tag]         v2.0.2 -> v2.0.2
 * [new tag]         v2.0.3 -> v2.0.3
$

Das konvertierte Projekt bei GitHub:
Repository bei GitHub

Die Historie bzw. der Network Graph nach dem Import:

Der Git Network Graph des Projektes "test-spring-simple"

Der Network Graph des Projektes 'test-spring-simple' (© Frank Rahn)

Die Literaturempfehlungen

  • Git und andere Systeme – Git und Subversion
  • Git – git-svn Documentation

Update am 25.09.2012

Das Konvertieren der SVN-Tag & Branches in Git Tags & Branches

Die folgenden Kommandozeilenbefehle stellen eine andere Art dar, die Subversion-spezifischen Branches und Tags nach Git zu konvertieren.

$ cp -rf .git/refs/remotes/tags/* .git/refs/tags
$ rm -rf .git/refs/remotes/tags
$
$ cp -rf .git/refs/remotes/* .git/refs/heads/
$ rm -rf .git/refs/remotes
$

Allerdings bevorzuge ich die Konvertierung über die Git Befehle, da diese auch die Datei .git/config verändern.

Update am 08.01.2017

Es wurden einige neu Erkenntnisse in den Beitrag eingearbeitet.

  • Über
  • Letzte Artikel
Frank Rahn
Frank Rahn
Frank Rahn ist Softwarearchitekt. Er unterstützt bei der Konzeption von Softwarearchitekturen mit Java-Technologie. Folge Sie ihm auf Facebook oder Twitter.

Benötigen Sie Unterstützung? Kontaktieren Sie ihn.

Hat Ihnen dieser Beitrag gefallen? Wir würden uns über Ihren Kommentar freuen! Bitte verwenden Sie Ihren bürgerlichen Namen.
Frank Rahn
Letzte Artikel von Frank Rahn (Alle anzeigen)
  • Wer ist der optimale Java Bean Mapper? - Freitag, 22. September 2023
  • Spring Boot Webanwendung: Die ersten Schritte (Tutorial) - Montag, 28. März 2016
  • Mainframe-Zugriff via Java - Sonntag, 04. Mai 2014
1 Kommentar/von Frank Rahn
Schlagworte: Git, Linux, Shell, SVN, Toolchain, Versionsverwaltung
Eintrag teilen
  • Teilen auf X
  • Teilen auf WhatsApp
  • Teilen auf LinkedIn
  • Per E-Mail teilen
  • Teilen auf Xing
https://www.frank-rahn.de/wp-content/uploads/svn-git-convert-network-graph.png 214 550 Frank Rahn /wp-content/uploads/logo.png Frank Rahn2012-09-23 17:25:272024-05-26 19:13:25Wie Du ein Subversion Repository (SVN) nach Git konvertierst
Das könnte Dich auch interessieren
Eine Festplatte Einige Tipps mit defekten Festplatten oder Partitionen
Schaubild des asymmetrisches Verschlüsselungsverfahrens GnuPG benutzen
Das Linux-Maskottchen: Pinguin Tux Flash BIOS unter Linux (Howto)
Debian Paketsystem APT (Advanced Packaging Tool)
Dieses Bild zeigt meinen IT-Werkzeugkasten Franks aktueller IT-Werkzeugkasten
Bild von Linux Dateimanager Nautilus Link-Count: Finden von versteckten Verzeichnissen unter Linux
1 Kommentar
  1. reik
    reik sagte:
    Montag, 14. Mai 2018 um 8:30 Uhr

    … netter beitrag, danke 🙂

    Antworten

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar Antwort abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Ihr Kommentar wird verschlüsselt an meinen Server gesendet. Erforderliche Felder sind mit * markiert.

Weitere Informationen und Widerrufshinweise finden Sie in meiner Datenschutzerklärung.

Wollen Sie kein neuen Beiträge mehr verpassen?
Dann abonnieren Sie bitte meinen Newsletter.
Meinen Newsletter abonnieren

Themen

  • Wer ist der optimale Java Bean Mapper?
  • Einführung in das Spring Framework, Boot, Batch, Data, REST, Security, Web, …
  • Franks aktueller IT-Werkzeugkasten
  • Git, GitHub, EGit, …

Navigation

  • Buchtipps
  • Newsletter
  • Weblinks
Search Search

Werbung

  • JProfiler
Beliebt
  • Das Klassendiagramm für den Java Bean Mapper Test am Beispiel "ByHand"
    Wer ist der optimale Java Bean Mapper?Freitag, 22. September 2023 - 20:59 Uhr
  • Das offizielle Logo von EGit
    GitHub mit Eclipse (EGit)Freitag, 26. Oktober 2012 - 16:15 Uhr
  • Grobe Übersicht üder den Spring Framework Container
    Einführung in das Spring FrameworkSonntag, 01. Mai 2011 - 18:30 Uhr
  • Die Stored Procedure "searchPersons" mit User-defined Types (UDT)
    Spring und Stored Procedure mit User-defined Types (Tut...Freitag, 26. Oktober 2012 - 21:45 Uhr
  • Spring Boot Webanwendung
    Spring Boot Webanwendung: Die ersten Schritte (Tutorial...Montag, 28. März 2016 - 16:29 Uhr
Schlagworte
Annotations AOP Architektur Autorisierung Cookies CRUD DAO DI Git HTML HTTP IoC Java Java EE Java SE JPA JSR Linux MVC Open Source Software PDF POJO REST (RESTful) ROCA Self-contained Systems Serviceorientierte Shell Sicherheit (Security) SOAP Spring SQL SVN Test Toolchain URI URL URN User-defined Type Versionsverwaltung VPN Webservice WS-* WSDL XML XML-Schema

Blogarchiv

Links

Mastodon
Twitter
LinkedIn
Xing
GitHub

Lizenz

Creative Commons Lizenzvertrag Die Texte (nicht Bilder) von Frank Rahn stehen unter einer Creative Commons Namensnennung - Keine Bearbeitungen 4.0 Deutschland Lizenz.

Affiliate-Links

Die mit (*) gekennzeichnete Links sind sogenannte Affiliate-Links. Kommt über einen solchen Link ein Einkauf zustande, werde ich mit einer Provision beteiligt. Für Sie entstehen dabei keine Mehrkosten. Wo, wann und wie Sie ein Produkt kaufen, bleibt natürlich Ihnen überlassen.

Blogkategorien

Copyright © Frank W. Rahn
  • Impressum / HaftungsausschlussDie notwendigen gesetzlichen Angaben dieser Webseite von Frank Rahn
  • DatenschutzerklärungDie Datenschutzerklärung von Frank Rahn
  • NewsletterKeine neuen Beiträge mehr verpassen!
  • BildnachweisDer komplette Bildnachweis von Frank Rahn
Link to: Großes Beispiel mit Git und GitHub Link to: Großes Beispiel mit Git und GitHub Großes Beispiel mit Git und GitHubDer Branch Graph vor dem Merge Link to: GitHub mit Eclipse (EGit) Link to: GitHub mit Eclipse (EGit) Das offizielle Logo von EGitGitHub mit Eclipse (EGit)
Nach oben scrollen Nach oben scrollen Nach oben scrollen

Wir setzen auf unserer Webseite verschiedene Arten von Cookies ein, die auf Ihrem Gerät gespeichert werden. Einige dieser Cookies sind für die einwandfreie Funktion der Webseite notwendig, während andere Cookies Ihnen ein besseres Besuchererlebnis bieten.

DatenschutzerklärungImpressumAlle Cookies akzeptierenKeine Cookies akzeptierenIndividuelle Cookie-Einstellungen vornehmen

Cookie- und Datenschutzeinstellungen



Wie wir Cookies verwenden

Wir setzen auf unserer Webseite verschiedene Arten von Cookies ein, die auf Ihrem Gerät gespeichert werden.

Einige dieser Cookies sind für die einwandfreie Funktion der Webseite notwendig, während andere Cookies Ihnen ein besseres Besuchererlebnis bieten.

Klicken Sie links auf die verschiedenen Reitern, um mehr zu erfahren. Sie können auch einige Cookie-Einstellungen individuell anpassen. Beachten Sie, dass das Blockieren einiger Cookies die einwandfreie Funktion unserer Webseite beeinträchtigt.

Technisch notwendige Cookies

Diese Cookies sind unbedingt erforderlich, denn sie ermöglichen grundlegende Funktionen und sind für die einwandfreie Funktion der Webseite erforderlich.

Sie können diese Cookies jederzeit blockieren oder löschen, indem Sie Ihre Browsereinstellungen ändern und die Blockierung aller Cookies auf dieser Webseite erzwingen. Leider werden Sie dann immer wieder gefragt, ob Sie Cookies akzeptieren oder ablehnen wollen, wenn Sie unsere Webseite erneut besuchen.

Wir setzen die Cookies aviaPrivacyEssentialCookiesEnabled, aviaPrivacyMustOptInSetting, aviaPrivacyRefuseCookiesHideBar und aviaCookieConsent ein, um Ihre individuellen Cookie-Einstellungen zu speichern. Diese Informationen geben wir an keinen Drittanbietern weiter.

Diese Cookies haben eine Laufzeit von einem Jahr, dann müssen Sie die Einstellungen wiederholen.

Die VG WORT setzt das Sitzungscookie srp zur Messung von Zugriffen auf Texten, um die Kopierwahrscheinlichkeit des Textes zu erfassen. Damit partizipieren ich an den Ausschüttungen der VG WORT, welche die gesetzliche Vergütung für die Nutzungen urheberrechtlich geschützter Werke gemäß § 53 UrhG sicherstellen. Das Cookie wird dazu verwendet, um den Nutzer zu identifizieren und ggf. Daten mehrerer Aufrufe von Texten miteinander verknüpfen zu können.

Nach Angaben der VG WORT stellt das eingesetzte Verfahren sicher, dass einzelne Nutzer oder ihr Leseverhalten nicht ermittelbar sind, wenn die Anzahl der Textaufrufe gezählt wird. Alle von der VG Wort erfassten Daten werden sofort sicher verschlüsselt. Der Einsatz des Zählpixels wurde durch das Bayerische Landesamt für Datenschutzaufsicht begutachtet und als datenschutzkonform bewertet.

Datenschutzerklärung der VG WORT

Marketing-Cookies

Die Marketing-Cookies werden von Drittanbietern oder Publishern, wie z. B. Google Analytics, verwendet, um personalisierte Werbung anzuzeigen. Sie tun dies, indem sie Besucher über Webseiten hinweg verfolgen (Tracking).

Wir setzen keine Marketing-Cookies ein.

Datenschutzbestimmungen

Sie können unsere Cookies und Datenschutzeinstellungen im Detail in unserer Datenschutzerklärung nachlesen.

Cookie-Einstellungen übernehmenKeine Cookies akzeptieren
Nachrichtenleiste öffnen Nachrichtenleiste öffnen Nachrichtenleiste öffnen