{"id":651,"date":"2011-09-01T20:21:41","date_gmt":"2011-09-01T18:21:41","guid":{"rendered":"http:\/\/blog.speedyj.de\/?p=651"},"modified":"2019-03-11T17:03:41","modified_gmt":"2019-03-11T15:03:41","slug":"svn-und-git-nutzen","status":"publish","type":"post","link":"https:\/\/blog.speedyj.de\/?p=651","title":{"rendered":"SVN und GIT nutzen"},"content":{"rendered":"

Als Entwickler geh\u00f6rt das Verwenden einer Versionsverwaltung<\/a> zur t\u00e4glichen Arbeit. In meinem Umfeld kommt dabei h\u00e4ufig („noch“) Subversion<\/a> (kurz „SVN“) zum Einsatz. Dabei handelt es sich um ein sogenanntes Zentrales Versionsverwaltungssystem, wo das Repository<\/a> durch einen zentralen Server verwaltet wird. Viele Aktionen (wie z.B. die History-Funktion und Commit) ben\u00f6tigen somit Zugriff auf diesen Server.<\/p>\n

Anders verh\u00e4lt es sich da bei den sogenannten „Verteilten Versionsverwaltungssystemen“. Hier wird auf dem eigenen Rechner eine Kopie des Repositories abgelegt (oder von einem Teil des Repositories). In dieser lokalen Kopie kann man jederzeit Branches erstellen, Commits durchf\u00fchren oder die Historie einsehen. Also egal wo man sich gerade aufh\u00e4lt, ob unterwegs, ob mit oder ohne Netzzugang, man kann an seiner eigenen Entwicklung weiterarbeiten. Zus\u00e4tzlich schlie\u00dfen diese verteilten Versionsverwaltungssysteme den Einsatz einer zentralen Repository-Kopie nicht aus. Man kann weiterhin ein zentralen Repository mit Zugang f\u00fcr jeden Entwickler bereitstellen.<\/p>\n

Da in letzter Zeit eins meiner zentralen SVNs hin und wieder nicht \u00fcbers Netz erreichbar war, habe ich nach einer Alternative gesucht, wie sich die Vorteile von einer verteilten Versionsverwaltung mit einer zentralen SVN-Verwaltung kombinieren lassen. Und kurzem Suchen im Netz bin ich auf git-svn<\/a> gesto\u00dfen. Dieses Tool erm\u00f6glich das Erstellen eines Git-Repositories auf Basis eines SVN-Repositories. An dem so erstellten Repo k\u00f6nnen \u00c4nderung vorgenommen werden und sp\u00e4ter wieder an das zentrale SVN \u00fcbertragen werden. Klasse, genau was ich brauchte. Zus\u00e4tzlich gibt es f\u00fcr Windows noch die TortoiseGit-Explorer-Erweiterung, die auch git-svn unterst\u00fctzt. Aber dazu sp\u00e4ter noch mehr.<\/p>\n

Lesematerial<\/strong><\/p>\n

Wer aus der „SVN-Welt“ kommt und auf ein verteiltes System wie Git wechselt, muss erstmal verstehen, wie ein solches System funktioniert. Auch gibt es neue Begrifflichkeiten, die man zumindest ansatzweise verstanden haben sollte. Eine relativ guten Einstieg habe ich im Online-Buch „Pro Git<\/a>“ gefunden. Eine Gegen\u00fcberstellung zwischen SVN- und Git-Befehlen kann man hier nachlesen<\/a>.<\/p>\n

Installation<\/strong><\/p>\n

Nun ging es an einen ersten Test. Daf\u00fcr habe ich die Git-Version 1.7.4 von http:\/\/git-scm.com<\/a> heruntergeladen und installiert. Die Installation von Git ist weitestgehend selbsterkl\u00e4rend. Nur die Einstellung „Line Ending Conversion“ ist nicht ganz selbsterkl\u00e4rend. Wenn man vorhat, mittels Git auf ein SVN-Repository zuzugreifen, dann sollte man hier „Checkout as-is, commit as-is“ w\u00e4hlen.<\/p>\n

\"\"<\/a><\/p>\n

Testen<\/strong><\/p>\n

Nach der Installation findet man im Windows-Startmen\u00fc die „Git Bash“, also die Kommandozeile f\u00fcr Git. Dabei handelt es sich um eine Unix-like Shell f\u00fcr Windows. Die Navigation im Dateisystem l\u00e4uft hier etwas anders als normalerweise unter Windows. So wechselt man mit „cd \/d“ auf das Laufwerk D:\\, und mittels „ls“ kann man sich den Inhalt des aktuellen Verzeichnisses auflisten.<\/p>\n

\"\"<\/a><\/p>\n

Mit folgender Zeile kann man mittels „git svn“ eine Kopie eines SVN-Repositories erstellen:<\/p>\n

$ git svn clone http:\/\/localhost\/svn\/arxml -s<\/span>\nInitialized empty Git repository in d:\/git_test\/arxml\/.git\/<\/span>\nr1 = 79ac10e9eacb0d38a1466fd2c834903afe81c2f8 (refs\/remotes\/trunk)<\/span>\n          A       api.h<\/span>\n          A       stdafx.h<\/span>\n...<\/span>\nr18 = d28954ccd89dad6eedf1331a1f8609c01cf1ce7b (refs\/remotes\/trunk)<\/span>\nChecked out HEAD:<\/span>\n  http:\/\/localhost\/svn\/arxml\/trunk r18 <\/span><\/pre>\n
Die Option „-s“ am Ende des Befehls gibt an, dass es sich um eine Standard-SVN-Sturktur mit Unterverzeichnissen „branches“, „tags“ und „trunk“ handelt. Wenn man das nicht getan hat, sollte man die Option weglassen oder falls man andere Name gew\u00e4hlt hat kann man das \u00fcber folgenden Befehl anpassen (wobei hier auch wieder die Standard-Namen eingesetzt wurden):<\/p>\n
$ git svn clone http:\/\/localhost\/svn\/arxml -T trunk -b branches -t tags<\/span><\/pre>\n
Also gut. Mit dem Befehl haben wir ein Git-Repository erstellt und dieses mit dem Inhalt eines SVN-Repository gef\u00fcllt. Mittels cd wechseln wir nun in den neu erstellten Ordner. Nach dem „git svn clone“ Befehl, wird normalerweise der master-Branch gew\u00e4hlt, welcher dem „trunk“ entspricht (oder falls man die Option -s weggelassen hat, die oberste Ebene).<\/p>\n
Wenn man also die Historie einsehen m\u00f6chte:<\/p>\n
$ git log<\/span><\/pre>\n
Hat man \u00c4nderungen an Dateien vorgenommen, kann man diese auch in das Repository \u00fcbertragen.<\/p>\n
$ git commit -am \"added new usage instructions\"<\/span><\/pre>\n
Da wir aber nun mit zwei Repositories arbeiten (lokal:Git und remote:SVN), hat der „git commit“ Befehl lediglich die \u00c4nderung in das lokale Git-Repository geschrieben. Um auch das SVN-Repo zu aktualisieren, nutzt man „git svn dcommit“:<\/p>\n
$ git svn dcommit<\/span>\nCommitting to http:\/\/localhost\/svn\/arxml ...<\/span>\n      M      Main.cpp<\/span>\nCommitted r19 <\/span>\n      M      Main.cpp<\/span>\nr19 = 854e82f4860d474a9a5db7bca6746d101448e100 (trunk)<\/span>\nNo changes between current HEAD and refs\/remotes\/trunk<\/span>\nResetting to the latest refs\/remotes\/trunk<\/span><\/pre>\n
Unsere \u00c4nderung sind jetzt im SVN und die Revisionsnummer (r19) wurde im Git-Repository vermerkt. Jetzt kann es nat\u00fcrlich vorkommen, dass in der Zwischenzeit ein anderer Entwickler \u00c4nderungen in das SVN-Repo \u00fcbertragen hat. In diesem Fall m\u00fcssen die \u00c4nderungen vor dem „dcommit“ in das Git-Repository geholt werden und das geht mit dem rebase-Befehl.<\/p>\n
$ git svn rebase<\/span>\n       M      notes.txt<\/span>\nr20 = c373de5f458c76f3b0e2e5027cd92eebeaa0e55d (trunk)<\/span>\nFirst, rewinding head to replay your work on top of it...<\/span>\nFast-forwarded master to refs\/remotes\/trunk.<\/span><\/pre>\n
Nun, das soll f\u00fcr’s erste reichen. Mehr Informationen zu den Befehlen findet man im git-svn-Manual<\/a>.<\/p>\n
Problem mit Zeilenenden<\/strong><\/p>\n
Etwas Schwierigkeiten hat mir sp\u00e4ter das automatische Konvertieren von Zeilenumbr\u00fcchen durch Git bereitet. Hier hat mir msysGit Issue 21<\/a> etwas weitergeholfen, wenn auch keine definitive Empfehlung gegeben. SVN k\u00fcmmert sich normalerweise nicht um die Inhalte von Dateien (siehe svnredbook<\/a>). D.h. wenn eine Datei unter Windows ins SVN \u00fcbertragen wird, enth\u00e4lt die Datei im Normalfall CRLF Umbr\u00fcche. Installiert man jedoch Git mit den Standardeinstellungen (core.autocrlf = true), dann wird jede Textdatei im Repository ins Unix-Style-LineEnding-Format (also LF) konvertiert. Bei der ausschlie\u00dflichen Nutzung von Git ist das sicherlich die beste Wahl. Wenn man jedoch mittels Git auf SVN zugreift, f\u00fchrt das automatische Umwandel zu Problemen (zumindest war es bei mir der Fall). Hat man wie weiter oben geschrieben ein SVN-Repo mittels „git svn“ geklont und \u00fcbertr\u00e4gt \u00c4nderungen (bei core.autocrlf=true) in das Git-Repository, dann enth\u00e4lt die Datei im Git-Repo lediglich LF-Umbr\u00fcche. \u00dcbertr\u00e4gt man diese Datei ins SVN, kann es dazu f\u00fchren, dass jede Zeile als ge\u00e4ndert markiert wird. Es ist also wichtig zu wissen, welche Zeilenumbr\u00fcche in den Dateien des SVN-Repo’s normalerweise verwendet werden.<\/p>\n
Viele Texteditor k\u00f6nnen mittlerweile mit den verschiedenen Zeilenumbr\u00fcchen umgehen. Deswegen k\u00f6nnte man schnell annehmen, dass es doch egal ist in, welche Umbr\u00fcche in der Datei verwendet werden. Fakt ist jedoch, das viele andere Tools (wie z.B. Compiler, Parser) h\u00e4ufig erwarten, dass in den Eingabedateien Zeilenumbr\u00fcche des jeweiligen Betriebssystems verwendet werden. Aus diesem Grund ist auch die autocrlf-Variable durchaus sinnvoll. Jedoch kann aus dem gleichen Grund keine allgemeine Festlegung f\u00fcr die Standardeinstellung von core.autocrlf gegeben werden. Je nach Projekt, eingesetzten Betriebssystemen und SVN-Konfiguration kann eine andere Wahl sinnvoll sein. F\u00fcr meine spezifischen Fall (SVN-Clients = Windows), muss autocrlf auf „false“ gesetzt werden.<\/p>\n
Jetzt nochmal, nur einfacher<\/strong><\/p>\n
Das ganze Arbeiten in der „Git-Bash“ ist ja sch\u00f6n und gut. Hilft auf jeden Fall dabei, die Arbeitsweise von Git besser zu verstehen. Aber wer TotoiseSVN<\/a> kennen und lieben gelernt hat, wird nur ungern darauf verzichten wollen. Zum Gl\u00fcck haben das ein paar Entwickler fr\u00fchzeitig erkannt. TortoiseGit<\/a> f\u00fcr Klicki-Bunties.<\/p>\n
Installationsreihenfolge<\/span><\/p>\n