go to start Git An Der Hsr
|home |print view |recent changes |changed February 1, 2013 |
exact
|You are 54.146.169.191 <- set your identity!

Sections: Zugang | Kurzanleitung zu [https://git.hsr.ch/ git.hsr.ch] und [https://svn.hsr.ch/ svn.hsr.ch] | Konvertieren von Subversion/=[svn]= nach =[git]= ''inklusive History'' | Vorbedingungen | Linux | Windows | Vorbereitung | Konvertieren von Namen/Email-Adressen der Autoren | Beibehalten(-) der svn-commit-ids oder nicht(+)? | Subversion Repository Layout | Zeichensätze | Partielle Konvertierung | Abfrage von aktuellen =[git]= Einstellungen | Konvertierung | Klonen starten | Import fortsetzen (falls dieser abgebrochen wurde) | Kurzkontrolle des konvertierten Repository | Vorbereiten des Repository für den ''upload'' | Repository auf https://git.hsr.ch vorbereiten | Repository anbinden und raufladen | Fragen und Antworten | Tipps | Speichern meines Usernamen / Passwort in der aktuellen Session (Linux) | Variante ohne feste Speicherung des Passwort | Variante mit Speicherung des Passwort in einer Datei | ''Option:'' Speichern der Zugangsdaten pro Repository |

Zugang ^

https://git.hsr.ch/

Kurzanleitung zu git.hsr.ch und svn.hsr.ch ^

HSR git und subversion HowTo

eclipse - EGit HowTo

Konvertieren von Subversion/svn nach git inklusive History ^

Diese Anleitung kann sowohl für Linux/Mac als auch für Windows verwendet werden, da unter Verwendung der Git Bash (Windows) die Kommandos identisch sind.

Die einzugebenden Kommandos sind jeweils alle dem $ Zeichen folgenden Zeichen.

abgedruckt
~/SEuebung (master)$ git init --bare ../`basename \`pwd\``.git
einzugeben
git init --bare ../`basename \`pwd\``.git

Grafische Tools - mit GUI - eignen sich meiner Meinung nach für eine Konvertierung nicht. Es sind zu viele Unsicherheiten in nicht korrekt übersetzten Begriffen vorhanden und die Funktionalität ist meist auf die am meisten gebrauchten Kommandos beschnitten.

Weitere Anleitungen zur Migration, wie auch zu anderen Themen betreffend git, findet man hier: http://git-scm.com/book/de/Git-und-andere-Versionsverwaltungen-Zu-Git-umziehen oder auch hier: http://john.albin.net/git/convert-subversion-to-git

TortoiseGit (Windows) könnte prinzipiell für die Konvertierung verwendet werden, die Möglichkeit Namen von Autoren während des Imports anzupassen gibt es jedoch nicht - und dies scheint mir eines der wichtigsten Dinge hierbei zu sein.

Vorbedingungen ^

Linux ^

Folgende Pakete - je nach Distribution können diese auch ein bisschen anders benannt sein - sollten installiert sein:

 git
 subversion

Windows ^

Ich empfehle zur Konvertierung die Git Bash zu verwenden, da die folgende Anleitung darauf abstützt. Das entsprechende Paket kann hier heruntergeladen werden: http://git-scm.com/download

Ein Kommandozeilenclient von subversion - brauchen wir nicht unbedingt - gibts hier: http://sourceforge.net/projects/win32svn/

 

Vorbereitung ^

Konvertieren von Namen/Email-Adressen der Autoren ^

Um die Kurznamen der svn-commits (z.B. HSR-Kürzel m1huber) auf Namen mit entsprechender Email Adresse abzubilden, also hierbei Marcel Huber <m1huber@hsr.ch>, muss eine entsprechende Konvertierungsdatei zusammengestellt werden. Wenn dieser Schritt nicht in die Konvertierung mit einbezogen wird, entstehen unsinnige pseudo Email Adressen in der Form <m1huber@9c1c318c-6dd0-4ce7-adff-8b867e8fa2bb>

Bei HSR internen Repositories auf svnf.hsr.ch oder svns.hsr.ch entsprechen die zugewiesenen Benutzernamen den erwähnten Kurznamen. Diese Namen können nun in eine Textdatei eingetragen und mit entsprechendem vollständigem Namen und Email Adresse ergänzt werden.

Das Zeilenformat dieser Datei ist wie folgt:

kurzname = Vorname Nachname <email>

Reales Beispiel:

m1huber = Marcel Huber <marcel.huber@hsr.ch>
m1stocke = Mirko Stocker <m1stocke@hsr.ch>

Die Datei, beispielsweise users.txt, kann dann zur Konvertierung durch folgende Kommandozeilenoption angegeben werden:

 --authors-file=users.txt

Beibehalten(-) der svn-commit-ids oder nicht(+)? ^

Der Import eines bestehenden svn-Repository zu git erlaubt die Beibehaltung der entsprechenden svn-revision zu jedem jemals durchgeführten commit.

Falls der Bedarf besteht, zu einen späteren Zeitpunkt wieder einmal mit dem entsprechenden svn Repository mittels git svn dcommit abzugleichen, muss diese Information gespeichert werden.

Meine Empfehlung ist, diese Information nicht ins git-Repository zu übernehmen. (MarcelHuber 17:43 January 31, 2013)

Kommandozeilenoption wenn man die Metainformationen nicht übernehmen will:

 --no-metadata

Subversion Repository Layout ^

Die Struktur eines Subversion Repository enthält üblicherweise die folgenden Verzeichnisse in der Basis:

 SEuebung
 |-- branches
 |-- tags
 |-- trunk

Damit Tags und Branches, für obige Struktur, bei der Konvertierung berücksichtigt werden, muss die folgende Option auf der Kommandozeile angegeben werden:

 --stdlayout

Wenn bei der Erstellung des Subversion Repository eine andere oder keine Struktur verwendet wurde, müssen andere Kommandozeilenoptionen angegeben werden, auf welche ich hier nicht eingehe. Weitere Informationen dazu findet man hier: http://git-scm.com/docs/git-svn

Zeichensätze ^

Sollten kryptische Zeichen anstelle von ä/ö/ü im git log erscheinen, kann man dies lokal pro Repository einstellen. Standardeinstellung bei git ist üblicherweise UTF-8, bei Windows kann es aber auch cp1252 sein. Die folgenden beiden Variablen steuern dieses Verhalten: (siehe auch http://git-scm.com/docs/git-config )

 i18n.commitEncoding
 i18n.logOutputEncoding

Partielle Konvertierung ^

Eine partielle Konvertierung ist üblicherweise nicht empfehlenswert!

Falls nicht die ganze Subversion Historie konvertiert werden soll, kann auch erst ab einer bestimmten Version gestartet werden:

 -r1:HEAD          # alles ab revision 1
 -r765:HEAD        # alles ab revision 765

oder nur ein Teilbereich:

 -r45:70           # von revision 45 bis revision 70

Abfrage von aktuellen git Einstellungen ^

Bei git können Optionen entweder global oder pro repository eingestellt werden.

Die Abfrage der momentan gesetzten Einstellungen geschieht mit folgendem Kommando:

$ git config -l

Sofern man sich zum Zeitpunkt der Abfrage nicht innerhalb eines Repository befindet, werden nur die globalen Optionen angezeigt.

Innerhalb eines Repository kann man die globalen Optionen ausblenden durch Angabe von --local, oder umgekehrt kann man sich nur die globalen Optionen mittels --global anzeigen lassen:

$ git config -l --local
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
svn-remote.svn.nometadata=1
svn-remote.svn.url=http://svns.hsr.ch/SEuebung
svn-remote.svn.fetch=trunk:refs/remotes/trunk
svn-remote.svn.branches=branches/*:refs/remotes/*
svn-remote.svn.tags=tags/*:refs/remotes/tags/*
i18n.commitencoding=utf-8
oder
$ git config -l --global
gui.encoding=utf-8

Konvertierung ^

Wenn nun alle Angaben bekannt sind, kann mit der eigentlichen Umstellung begonnen werden. Dazu startet man die Git Bash und vergewissert sich duch Eingabe von pwd, in welchem Verzeichnis man sich zur Zeit befindet.

In diesem Verzeichnis wird der git-Klon des Subversion Repository in einem Unterverzeichnis mit gleichem Namen wie das Subversion Repository angelegt.

Klonen starten ^

Nachfolgende Kommandozeile dient als Beispiel des Aufrufs und muss aufgrund der gewünschten Konvertierungsoptionen und des Repositorynamen angepasst werden:

$ git svn clone --no-metadata --stdlayout --username m1huber --authors-file=users.txt http://svns.hsr.ch/SEuebung
Mit diesem Aufruf wird

  1. im erstellten git-Repository keine svn-Metainformationen gespeichert: --no-metadata
  2. davon ausgegangen, dass das svn-Repository dem Standard Layout entspricht: --stdlayout
  3. eine Anmeldung mit dem vergebenen Benutzer m1huber durchgeführt:--username m1huber, dabei wird das Passwort nachfolgend abgefragt
  4. eine Anpassung der Commit Autoren vorgenommen: --authors-file=users.txt
  5. das SEuebung Repository verwendet: http://svns.hsr.ch/SEuebung

Wenn keine Fehlermeldung erscheint und der Import als letzte Zeile die wirklich letzte Versionsnummer im Subversion Repository ausgibt, war der Import erfolgreich.

Import fortsetzen (falls dieser abgebrochen wurde) ^

Wenn während des Import zum Beispiel die Netzwerkverbindung getrennt wird oder der svn Server einen Fehler meldet, kann man an der Stelle wieder aufsetzen, an der abgebrochen wurde. Dazu wechselt man ins entsprechende Verzeichnis des Repository und führt nachfolgend das folgende Kommando aus:

$ cd SEuebung
 # Vorgang erneut starten
$ git svn fetch

Dieser Vorgang kann solange wiederholt werden, bis alle Subversion Revisions importiert sind.

Falls Probleme beim Import aufgetreten sind, muss anschliessend noch eine zusätzliche Operation ausgeführt werden:

$ git rebase trunk
Damit wird der aktuelle master Branch auf die letzte svn Revision gesetzt.

Kurzkontrolle des konvertierten Repository ^

Wenn man sich die Historie aller Commits anzeigen möchte, kann man das folgende Kommando verwenden:

$ git log --pretty=format:"%h %ad |%d %s [%an]" --graph --date=short --all

 * 6827035 2010-12-23 | (tags/myMessageTag) some other tag with a message [foo]
 * 05e4348 2010-12-22 | (HEAD, trunk, master) bla added [foo]
 * de9c6b9 2010-12-14 | english-Deutsch Fehler korrigiert [foo]
 * 555a10a 2010-12-14 | Files für die Übung [foo]
 | * bb9a918 2010-12-14 | (blubby1.0fix) fixup blubby1.0 [foo]
 | * bdbc9b2 2010-12-14 | (tags/blubby1.0) Create tag blubby1.0 [foo]
 | | * 65d7964 2010-12-14 | (blubby) file2 added [foo]
 | |/
 | * 58d5064 2010-12-14 | new commit [foo]
 | * 80ed724 2010-12-14 | Create branch blubby [foo]
 |/
 | * 8e32a97 2010-12-14 | (tags/MyTag) somefile added [foo]
 | * 966e4af 2010-12-14 | Create tag MyTag [foo]
 |/
 * 7279a60 2010-12-13 | initial import [foo]
 * 50e6ffb 2010-12-13 | adding missing stdlayout directories [foo]
In dieser Ansicht sind auch Branches und Tags in Relation zum entsprechenden Commit und der Historie ersichtlich.

Möchte man sich hingegen anzeigen lassen, ob und welche Tags/Branches importiert wurden, kann man folgendes Kommando verwenden:

$ git branch -av
1: * master                    05e4348 bla added
2:   remotes/blubby            65d7964 file2 added
3:   remotes/blubby1.0fix      bb9a918 fixup blubby1.0
4:   remotes/tags/MyTag        8e32a97 somefile added
5:   remotes/tags/blubby1.0    bdbc9b2 Create tag blubby1.0
6:   remotes/tags/myMessageTag 6827035 some other tag with a message
7:   remotes/trunk             05e4348 bla added
#    ^^^^^^                    ^^^^^^^ ^^^^^^^
#    a                         b       c
Kurze Erklärung zum Output, (Nummernangabe entspricht Zeilennummer im Output):

a
reference-name, Name eines bestimmten branches/tags, lokale Branches haben nie einen Präfix. Ein Präfix, hier remotes, zeigt an, dass die Referenzen von einem externen Repository stammen. Hierbei war dies durch den Import von Subversion entstanden.
b
sha1-id, erste 7 Zeichen der eindeutigen commit-ID
c
commit message, erste Zeile der commit Meldung zu b
1
* markiert den aktuellen Branch auf dem wir uns befinden und master ist der default Name dafür. Da dieser Name ohne remotes Prefix erscheint, sprechen wir hier von einem lokalen Branch. Die nachfolgenden 7 Zeichen sind Teil des zum commit gehörenden sha1 Hash welche man im obenstehenden git log ... Output wieder findet. Da hier der Hash dem von Zeile 7 entspricht, können wir davon ausgehen, dass master die lokale Arbeitskopie von remotes/trunk ist.
2,3
hierbei handelt es sich um Namen von Branches, welche zu einem bestimmten Zeitpunkt in der Historie angelegt wurden.
4,5,6
Hierbei handelt es sich um Tags, also Zeitpunkte in der Historie des Repository. Diese können wiederum im obenstehenden git log ... gefunden werden
7
trunk entspricht dem aktuellsten commit aus subversion

Wenn wir eine Situation dieser Art vorliegen haben, wir können wir also daraus ablesen, dass wir aktuell den Zustand des master branch ausgecheckt haben und dieser auf remotes/trunk basiert.

Würden wir den vorliegenden Stand ohne weitere Anpassungen auf git.hsr.ch ablegen, würde nur der master hochgeladen aber keine Branches und Tags. Das heisst, wir hätten nicht die ganze Historie abgelegt, sondern nur einen kleinen Teil davon. Haben wir weder Branches noch Tags definiert, wäre dies jedoch möglich.

Vorbereiten des Repository für den upload ^

Damit wir, wie gerade eben erwähnt, weder Branches noch Tags im neuen git Repository verlieren, müssen wir die zusätzliche Operationen durchführen. Hier wird dies wieder am Beispiel von SEuebung gezeigt, kann aber durch die Generizität der folgenden Kommandos für jedes Repository angewendet werden.

Vor Ausführung der folgenden Kommandos ist wichtig, dass man sich im Basisverzeichnis des konvertierten Repository befindet! Am Ende dieser Abfolge befindet man sich in einem speziellen bare Repository, welches nicht modifiziert werden darf.

~/SEuebung (master)$ git init --bare ../`basename \`pwd\``.git
Initialized empty Git repository in c:/Users/misto/SEuebung.git/

~/SEuebung (master)$ ( cd ../`basename \`pwd\``.git && git symbolic-ref HEAD refs/heads/trunk )

~/SEuebung (master)$ git remote add bare ../`basename \`pwd\``.git

~/SEuebung (master)$ git config remote.bare.push 'refs/remotes/*:refs/heads/*'

~/SEuebung (master)$ git push bare
Counting objects: 30, done.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (30/30), 460.00 KiB, done.
Total 30 (delta 11), reused 30 (delta 11)
To ../SEuebung.git
 * [new branch]      blubby -> blubby
 * [new branch]      blubby1.0fix -> blubby1.0fix
 * [new branch]      tags/MyTag -> tags/MyTag
 * [new branch]      tags/blubby1.0 -> tags/blubby1.0
 * [new branch]      tags/myMessageTag -> tags/myMessageTag
 * [new branch]      trunk -> trunk

~/SEuebung (master)$ cd ../`basename \`pwd\``.git

~/SEuebung.git (BARE:trunk)$ git branch -m trunk master

~/SEuebung.git (BARE:master)$ 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

Deleted branch tags/MyTag (was 8e32a97).
Deleted branch tags/blubby1.0 (was bdbc9b2).
Deleted branch tags/myMessageTag (was 6827035).

~/SEuebung.git (BARE:master)$ git branch -av
  blubby        65d7964 file2 added
  blubby1.0fix  bb9a918 fixup blubby1.0
* master        05e4348 bla added

~/SEuebung.git (BARE:master)$ git tag -l -n2
MyTag           somefile added
blubby1.0       Create tag blubby1.0
myMessageTag    some other tag with a message

~/SEuebung.git (BARE:master)$ git gc --aggressive --prune=now
Counting objects: 30, done.
Compressing objects: 100% (23/23), done.
Writing objects: 100% (30/30), done.
Total 30 (delta 11), reused 0 (delta 0)

Wenn diese Schritte durchgeführt wurden, haben wir ein sauberes und vollständiges git Repository, welches wir nur noch auf https://git.hsr.ch ablegen (pushen) müssen.

Repository auf https://git.hsr.ch vorbereiten ^

Damit das konvertierte git Repository auf https://git.hsr.ch abgelegt werden kann, müssen wir uns auf https://git.hsr.ch anmelden und ein neues git-Repository mit gewünschtem Namen anlegen.

-> Siehe Anleitung HSR git und subversion HowTo

Repository anbinden und raufladen ^

Im Moment haben wir eine vollständige lokale Kopie des gesamten Repository vorliegen. Damit wir unsere Arbeit nun mit anderen teilen können, definieren wir git.hsr.ch als unser remote Repository.

Remote Repository anbinden

~/SEuebung.git (BARE:master)$ git remote add origin https://m1huber@git.hsr.ch/git/SEuebung
Hierbei legen wir fest, dass unser remote Repository https://m1huber@git.hsr.ch/git/SEuebung unter dem Kurznamen origin angesprochen werden soll. Dies ist auch gleich der git übliche Name, welcher automatisch definiert wird beim Klonen eines remote Repository.

Raufladen des Repository

~/SEuebung.git (BARE:master)$ git push origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/*
Password for 'https://m1huber@git.hsr.ch':
Counting objects: 30, done.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (30/30), 460.00 KiB, done.
Total 30 (delta 11), reused 30 (delta 11)
remote: Resolving deltas: 100% (11/11)
remote: Updating references: 100% (6/6)
To https://m1huber@git.hsr.ch/git/SEuebung.git
 * [new branch]      blubby -> blubby
 * [new branch]      blubby1.0fix -> blubby1.0fix
 * [new branch]      master -> master
 * [new tag]         MyTag -> MyTag
 * [new tag]         blubby1.0 -> blubby1.0
 * [new tag]         myMessageTag -> myMessageTag
Die Angaben refs/heads/*:refs/heads/* und refs/tags/*:refs/tags/* bestimmen, dass wir alle lokalen Branches sowie die konvertierten Tags raufladen möchten.

Fragen und Antworten ^

Q
Welche git Zugangsprotokolle werden unterstützt?
A
Es wird nur der Zugang mittels https unterstützt. Damit ist die Übertragung sensitiver Daten gesichert und zudem kann man damit aus fast jeder Umgebung zugreifen - was z.B. beim git oder auch ssh Protokoll nicht immer der Fall ist. Zudem erspart man sich das, vor allem unter Windows mühsame, ssh-key Handling.

Q
Warum ist das Zertifikat für svn.hsr.ch nicht vertrauenswürdig?
A
Das Zertifikat ist nur für interne Verwendung von der HSR signiert.

Tipps ^

Speichern meines Usernamen / Passwort in der aktuellen Session (Linux) ^

Referenz
http://git-scm.com/docs/gitcredentials.html

Verfügbar ab git >= 1.7.9.

Nachfolgend sind Konfigurationsbeispiele für zwei der Varianten angegeben welche von mir (MarcelHuber 17:47 August 24, 2012) auch entsprechend ausprobiert wurden. Bei beiden Varianten wird vorerst davon ausgegangen, dass dasselbe User:Password Tupel für alle Repositories auf dem Server verwendet werden soll.

Variante ohne feste Speicherung des Passwort ^

Referenz
http://git-scm.com/docs/git-credential-cache.html

Die nachfolgende Konfiguration nutzt einen vorhandenen Session-Key Speicher (z.b. seahorse) falls dieser vorhanden ist. Damit das Passwort nicht ständig wieder eingegeben werden muss wird zusätzlich ein flüchtiges caching von git benutzt, welches seine Gültigkeit in diesem Beispiel nach 10 Stunden verliert.

 git config --global credential.https://git.hsr.ch.username MeinBenutzerName
 git config --global credential.helper 'cache --timeout 36000'
Beim nächsten Aufruf von clone/pull/fetch wird das Passwort abgefragt und für die angegebene Zeit ohne weitere Aufforderung gespeichert.

Wenn man den entsprechenden git-credential-cache--daemon vorzeitig beenden möchte, kann man diese mittels folgendem Aufruf tun:

 git credential-cache exit

Variante mit Speicherung des Passwort in einer Datei ^

Referenz
http://git-scm.com/docs/git-credential-store.html

Diese Variante ist zwar nützlich aber mit einem zusätzlichen Sicherheitsrisiko verbunden, da das Passwort im Klartext in der Datei gespeichert wird! []

 git config --global credential.https://git.hsr.ch.username MeinBenutzerName
 git config --global credential.helper 'store'

Option: Speichern der Zugangsdaten pro Repository ^

Referenz
http://git-scm.com/docs/gitcredentials.html

Falls eine Steuerung der Zugansgdaten inklusive Pfad stattfinden soll kann man dies allgemein mit folgender Option einstellen:

 git config --global credential.usehttppath true

Dabei muss man natürlich jetzt für jede in Frage kommende Repository-URL einen entsprechenden Konfigurationsbefehl absetzen. Beispielsweise:

 git config --global credential.https://git.hsr.ch/git/MeinRepository.username MeinBenutzerName

Diese Option kann als Ergänzung für beide vorangegangenen Varianten verwendet werden.


|home |print view |recent changes |changed February 1, 2013 |
exact
|You are 54.146.169.191 <- set your identity!

Git An Der Hsr
go to start