SVN How-To Fragen, Anregungen oder Vorschläge an Jochen.

SVN testen Wer erstmal ein bisschen mit Subversion rumspielen will, der kann sich ein lokales Repository anlegen. Wie das geht steht hier: http://www.codeproject.com/KB/winsdk/SubversionOnWindows.aspx (Ist zwar für Windows geschrieben, funktioniert aber für andere Betriebssysteme ganz genau so – einfach die entsprechenden Binaries downloaden und die Pfade austauschen.)

Zur Notation Bei den Anweisungen steht in Anführungszeichen (“”) der Eintrag aus einem Menü in Eclipse (wenn nicht dabei steht welches Menü, dann ist das „Team Menü“ gemeint) und hinten dran steht in eckigen Klammern ([]) der entsprechende SVN Kommandozeilen Befehl.

Prinzipielles zur Benutzung von Versionskontrollsystemen Versionskontrollsysteme dienen dazu alle Änderungen, die an einem Projekt gemacht werden, mitzuprotokollieren und die Änderungen unterschiedlicher Entwickler zusammen zu führen. Beispiel: Entwickler A ändert Zeile 17 in Datei 1 und Entwickler B ändert Zeile 19 in Datei 1 und SVN erkennt wer was wo geändert hat und fügt beide Änderungen zusammen. Oder: Entwickler A ändert etwas an Datei 2 und lädt die Datei auf den SVN Server. Dann merkt aber irgendwer, dass die Änderungen Blödsinn waren. Dann kann man SVN anweisen eine vorherige Version der Datei wiederherzustellen. Die Arbeitweise mit SVN ist die folgende: Man holt sich ein Abbild des Projektes vom SVN Server (die so genannte Working Copy). Dann arbeitet man an dem Projekt und wenn man fertig ist, dann lädt man seine Working Copy wieder auf den SVN Server hoch, damit die anderen Entwickler Zugriff auf die neue Version haben. Wenn man längere Zeit am Stück arbeitet, sollte man aber auch zwischen durch immer mal wieder seine Working Copy hoch laden um einerseits die Daten auf dem Server zu sichern und um die Änderungen auch teilweise rückgängig machen zu können und andererseits damit es nicht passieren kann, dass zwei Entwickler gleichzeitig an der selben Sache arbeiten und erst Stunden später merken, dass ein anderer das selbe geschrieben hat und damit die Arbeit des einen umsonst ist. Ein Problem, dass dadurch entsteht ist: Entwickler A ändert Zeile 5 in Datei 3 und Entwickler B ändert ebenfalls Zeile 5 in Datei 3. Entwickler A lädt seine Version der Datei hoch und wenn Entwickler B seine Version der Datei hoch laden will kann SVN nicht entscheiden wie die endgültige Version der Datei aussehen soll, da beide Entwickler die gleiche Zeile geändert haben. Dieses Problem nennt man einen Konflikt und dieser muss per Hand aufgelöst werden (im Beispiel von Entwickler B). Beim Auflösen des Konflikts muss Entwickler B entscheiden, ob der seine eigenen Änderungen verwirft und die Änderungen von Entwickler A übernimmt oder die Änderungen von Entwickler A verwirft und seine Änderungen übernimmt oder ob er beide Änderungen vereinen kann. In jedem Fall entscheidet Entwickler B darüber wie die endgültige Version der Datei aussieht. Hat er den Konflikt gelöst, so enthält seine Working Copy die endgültige Version und er kann diese auf den SVN Server hoch laden.

Subclipse (SVN in Eclipse) SVN findet sich in Eclipse im „Team-Menü“ - Rechtsklick auf eine Datei/einen Ordner/ein Projekt:

SVN Repository hinzufügen und den Trunk auschecken / sich eine „Working Copy“ holen Dies muss man nur ein Mal machen um die Dateien auf seinen Rechner zu holen. Sind die Dateien auf dem Rechner durchläuft man nur noch den „Normalen Arbeitsablauf“.

1.) Window → Open Perspective → SVN Repository Exploring (Unter Umständen muss man erst auf “Other…” klicken)

2.) Rechtklick in das „SVN Repository“ Register auf der linken Seite → New → Repository Location…

3.) URL eingeben 4.) „OK“ klicken 5.) Rechtsklick auf den Teil des Repositories, an dem man Arbeiten möchte →

Checkout… [svn checkout]

6.) „Check out as a project configured using the New Project Wizard” um neues Projekt zu erstellen oder die zweite Option um es in ein bereits bestehendes Projekt einzufügen

7.) “Finish” klicken 8.) Einstellungen für das Projekt vornehmen (diese Einstellungen sind lokal, d.h. sie

werden nicht auf den SVN Server hochgeladen)

Normaler Arbeitsablauf Wichtig ist: Vor jedem Commit sollte ein Update ausgeführt werden (Commit funktioniert im Falle eines Konfliktes aber sowieso nicht, d.h. man macht nichts kaputt, wenn man es vergisst).

1.) “Update” [svn update] 2.) Arbeiten 3.) “Update“ [svn update]

Bei einem Konflikt werden jetzt 3 Dateien erstellt: eine *.mine, eine *.rXXX und eine *.rYYY. Die *.mine ist die Datei wie ihr sie commiten wolltet. Die beiden anderen Dateien sind die aktuelle Revision vom SVN (HEAD) und die Revision vorher. Die Dateien

4.) Wenn Konflikt, dann für jede Datei mit Konflikt “Edit conflicts” Es öffnet sich dann der so genannte Diff-View. Auf der linken Seite sieht man die Datei, wie sie nach Abschluss des Auflösens aussieht und auf der rechten Seite sieht man die aktuelle Revision vom SVN. Zu Beginn ist die linke Seite identisch mit eurer Datei. Als erstes kann man getrost den „Copy all Non-Conflicting Changes From Right to Left” Button drücken (oben rechts in der Ecke). Danach geht man alle conflicting Changes (rot) durch und kann dann entweder den „Copy current Change from Right to Left“ Button benutzen (vorher die Zeile mit dem Konflikt markieren) oder wenn einem dieser Vorschlag nicht gefällt einfach die linke Seite per Hand ändern. Wenn alle Konflikte aufgelöst sind File → Save.

5.) Für jede Datei mit aufgelösten Konflikten „Mark Resolved“ Die restlichen Schritte entfallen, wenn man alle eigenen Änderungen mit denen vom Server überschrieben hat.

6.) “Commit…” [svn commit] 7.) Kommentar eingeben 8.) Dateien auswählen, die hoch geladen werden sollen 9.) “OK” klicken

Achtung: Leider gibt es noch eine kleine Falle bei Subversion: Subversion hat kein “echtes Renaming“, d.h. wenn man eine Datei umbenennt, dann erstellt Subversion eine neue Datei mit dem neuen Dateinamen (newFile.txt) und löscht die alte Datei (oldFile.txt). Problem dabei: Arbeitet jemand gleichzeitig an der Datei oldFile.txt, so erkennt Subversion nicht, dass die Änderungen in die neue Datei newFile.txt übernommen werden müssten, da dies (für SVN) eine unabhängige Datei ist. Stattdessen will SVN die Datei oldFile.txt als neue Datei hinzufügen (für SVN sieht es so aus als wäre die Datei neu hinzugefügt worden, da die ursprüngliche oldFile.txt gelöscht wurde). Wenn also eine Datei nach dem Updaten als neu hinzugefügt angezeigt wird, obwohl sie eigentlich nicht neu ist, dann am besten im Log nachschauen, ob jemand eine Umbenennung vorgenommen hat und dann per Hand die Änderungen in die Datei mit dem neuen Dateinamen übernehmen. Noch ein Hinweis zu Dateinamen: Windows hat ein case-insensitive filesystem. Deshalb dürfen sich Dateien nicht nur in der Groß- und Kleinschreibung unterscheiden sonst gibt’s Probleme mit dem Update! (Beispiel: myFile.cpp = myfile.cpp bei Windows)

Kommentare Die Kommentare beim SVN Commit sollten einfach nur beschreiben was man wo gemacht hat. Man sollte also den Ort der Änderung in Form von Namespace::Klasse::Methode bzw. einfach nur Namespace::Klasse angeben und dann was man gemacht hat. Idealerweise erstellt man während dem Arbeiten bereits die Logmessages in einer Textdatei. So stellt man sicher, dass man keine Änderung vergisst und erhält Logmessages anhand derer man direkt aus dem SVN erkennen kann, was in einer Revision genau geändert wurde. Dies ist besonders hilfreich, wenn man eine bestimmte Änderung rückgängig machen will. Dann findet man diese Änderung nämlich bereits mit Hilfe der Logmessages und muss nicht die Dateien durchsehen. Wenn man die SVN Kommandozeilenbefehle benutzt kann man die Logdateien sogar beim Commit direkt mit angeben. Subclipse unterstützt dass leider nicht → good old copy+paste muss herhalten. Hier ein paar Vorschläge, wie gängige Kommentare aussehen könnten: Namespace::Klasse::Methode – created/removed Namespace::Klasse::Methode – bugfix (TracID: XXX) Namespace – ported RXXX from trunk Namespace – merged branch “mybranch” into trunk Namespace::Klasse::Methode – renamed to “NewMethodName” Namespace::Klasse::Methode – renamed parameter ”myParameter” to “myNewParameter” someFile.cpp – renamed to “newFileName.cpp” /branches/myBranch – created branch from trunk Namespace::Klasse::Methode – resolved conflicts with rXXX

Änderungen Rückgängig machen Wenn man feststellt, dass irgendwelche Änderungen, die man gemacht hat falsch waren, dann kann man mit „Revert…“ die Änderungen wieder rückgängig machen. Allerdings wird immer die komplette Datei wiederhergestellt, d.h. alle lokalen Änderungen an der Datei werden rückgängig gemacht.

SVN Repository Struktur root → trunk → graphics physics sound core data → maps items units ai logic branches → graphics → graphics_feature1_test graphics_feature2_test physics → physics_feature1_test sound → core → data → ai →

logic → release_candidate (nur bugfixes) tags → alpha beta gold

Was sind Branches/Tags/Trunk? Branches sind nebenläufige Entwicklungszweige, d.h. wenn man z.B. einen Teil der Software komplett umgestaltet oder eine experimentelles Feature einbauen will, aber andere Programmierer trotzdem weiterhin eine lauffähige Version der Software haben sollen um an anderen Teilen der Software weiter zu arbeiten, dann erstellt man einen Branch. SVN erstellt dann eine Kopie des Trunks, d.h. der aktuellen Hauptentwicklungslinie, und man entwickelt dann mit diesem Branch, statt mit dem Trunk (man kann auch Branches von Branches erstellen oder sogar aus verschiedenen Revisionen einen Branch zusammen stellen, dass aber nur am Rande). Der Branch ist dann praktisch unabhängig und kann als eine Art eigenes Projekt betrachtet werden. Hat man seine Arbeit am Branch abgeschlossen so führt man die Änderungen in den Trunk ein und mit einem „Commit“ ist das neue Feature integriert. Im Konzept von SVN sind Branches und Tags das gleiche. In anderen Versionskontrollsystemen sind Tags praktisch Backups, d.h. man erstellt eine Kopie einer gewissen Revision (=Version der Entwicklung) und diese Kopie kann nicht mehr verändert werden. In SVN wird so was einfach dadurch realisiert, dass man einen Branch erstellt und diesen nicht mehr verändert oder z.B. nur noch Bugfix Änderungen zulässt. So kann man z.B. Stable / Release Versionen realisieren (Branch „Release X.X“ erstellen und nur noch Bugfixes zulassen).

Einen Branch erstellen 1.) Ordner erstellen (Rechtsklick wohin der Ordner soll -> New -> Folder), Name des

Ordners = Name des Branches Wichtig: SVN kann immer nur den letzten Ordner in der Hierarchie gleich beim entsprechenden Befehl erstellen, d.h. “svn copy http://svn.my-svn-server.com/trunk http://svn.my-svn-server.com/branches/xy_test“ funktioniert nur, wenn der Ordner „branches“ bereits existiert. Der Ordner „xy_test“ muss allerdings nicht existieren.

2.) “Branch/Tag…” [svn copy] 3.) Revision auswählen (in der Regel “HEAD”, d.h. aktuelle Revision) 4.) Zielordner eingeben/auswählen 5.) Kommentar eingeben 6.) „OK“ klicken

An einem Branch arbeiten Einen Branch auschecken funktioniert genauso wie den Trunk auschecken (siehe oben). Der Arbeitszyklus ändert sich jedoch. Der Grund dafür ist, dass aufgrund der Nebenläufigkeit Änderungen, die am Trunk vorgenommen werden, nicht automatisch in den Branch übernommen werden. Dies ist aber teilweise erwünscht, teilweise aber auch unerwünscht. Beispielsweise könnte eine Klasse in einem Branch überarbeitet oder neu geschrieben werden, z.B. weil es sich um eine zentrale Klasse handelt und eine unfertige Variante der Klasse gravierende Einschränkungen in der Arbeit der anderen Entwickler bedeuten würde.

Jetzt werden aber während dessen Änderungen in der gleichen Klassen im Trunk vorgenommen. Da diese Änderungen aber die alte Variante der Klasse betreffen sind diese für die neue Variante vielleicht nicht mehr relevant. Es könnte aber auch sein, dass die Änderungen Teile der Klasse betreffen, die aus der alten Variante übernommen wurden. Daher ist eine Übernahme von Änderungen aus dem Trunk teilweise wünschenswert. Prinzipiell gibt es zwei Arbeitsabläufe. Der eine Arbeitsablauf ist identisch mit dem „normalen Arbeitsablauf“ des Trunks. Auf diese Weise werden jedoch nur Änderungen zwischen der Working Copy und dem Branch synchronisiert. Änderungen, die am Trunk vorgenommen wurden müssen explizit übernommen werden. Dieses Übernehmen von Änderungen vom Trunk nennt man „portieren“. Das Problem beim Portieren ist, dass der Entwickler dies größtenteils selbst machen muss. Es kann nämlich durchaus passieren, dass durch die Übernahme von Änderungen aus dem Trunk Fehler im Branch entstehen. Beispiel: Die Parameter von Methode A werden im Branch geändert. An einer Methode B werden im Trunk Änderungen vorgenommen und Methode B ruft danach Methode A auf, jedoch noch mit den alten Parametern. Übernimmt man die Änderungen aus dem Trunk in den Branch, so wird es zu einem Fehler beim kompilieren kommen. Daher müssen Entwickler eines Branches Änderungen, die sie aus dem Trunk übernehmen, stets kontrollieren (Nur falls Zweifel aufkommen: So etwas kann nicht passieren, wenn Methode A ebenfalls im Trunk geändert worden wäre, da diese Änderungen dann für den Entwickler, der Methode B geändert hat, sichtbar wären). Ein weiteres Problem, dass Subversion mit Version 1.5 aber glücklicherweise lösen wird, ist dass man Änderungen aus dem Trunk doppelt übernimmt. Beispiel: Man portiert irgendwas aus dem Trunk in seinen Branch und ändert danach genau diese Stelle. Wenn man jetzt wieder Änderungen portiert, so erkennt Subversion nicht, dass man diese Stelle bereits aus dem Trunk portiert und im Nachhinein geändert hat. Subversion geht deshalb davon aus, dass diese Stelle ebenfalls (wieder) portiert werden muss. Um dieses Problem zu umgehen ist es daher wichtig, dass man beim Portieren im Kommentar angibt, welche Revision des Trunks man portiert, damit man beim nächsten Portieren nur spätere Revisionen portiert. Mit Version 1.5 wird es auch möglich sein nur spezielle Änderungen einer Revision zu portieren, was die Menge an Kontrollen verringert.

Änderungen vom Trunk in den Branch portieren Dies sollte man am besten einmal tun bevor man anfängt zu arbeiten. Während dem Arbeiten kann man dan mit dem „normalen Arbeitsablauf“ am Branch arbeiten.

1.) “Update” [svn update] 2.) “Merge…” [svn merge]

Mergen ist eine allgemeinere Form von Portieren. Beim Mergen kann man beliebige Revisionen von beliebigen Branches bzw. vom Trunk zusammenführen. Portieren ist in SVN so realisiert, dass man einen Merge durchführt, der den Trunk und einen Branch zusammen führt. Das Problem ist jetzt nur, dass beim Mergen sehr leicht falsche Angaben gemacht werden, da das Konzept etwas unintuitiv ist. Im Abschnitt „Branch in den Trunk mergen“ wird dies deutlich werden. Für diesen Abschnitt reicht es zunächst einmal einfach nur darauf zu achten, dass man die korrekten Verzeichnisse / Revisionen ausgewählt hat.

3.) Bei „From“ als URL zunächst den Branch auswählen (das wird gleich wieder geändert)

4.) „Show Log“ bei „From“ anklicken 5.) Die History von oben nach unten bis zum ersten Eintrag „Ported rXXX from trunk“

durchsuchen. Wenn ein solcher Eintrag existiert, dann zu XXX eins addieren, merken und „Cancel“ klicken. Wenn kein solcher Eintrag existiert (d.h. wenn zum ersten Mal etwas vom Trunk portiert wird), dann unten links in der Ecke „Stop on Copy/Move“

auswählen und den Eintrag mit der kleinsten Revisionsnummer auswählen und „OK“ klicken.

6.) Jetzt bei „From“ als URL den Trunk auswählen 7.) Wenn man in Schritt 5 einen „Ported rXXX from Trunk“ Eintrag gefunden hatte, dann

noch bei der „Revision“ noch die gemerkte Zahl, d.h. XXX+1, eintragen. 8.) Bei „To“ muss „Use ‘From’: URL” ausgewählt sein 9.) „Show Log“ bei „To“ anklicken 10.) Die größte Revisionsnummer (YYY) merken, diesen Eintrag auswählen und „OK“

klicken 11.) „Merge“ klicken 12.) Wenn Konflikt, dann Konflikt auflösen analog zu Schritt 4. und 5. des „normalen

Arbeitsablaufs“ 13.) Änderungen kontrollieren

Am einfachsten kontrolliert man die Änderungen indem man alle Dateien, die als geändert markiert sind (Sternchen-Symbol an Datei) mit der vorherigen Version der Working Copy vergleicht: Rechtsklick → Compare With → Base Revision. Jetzt kann man wie gewohnt die Änderungen vom Trunk (sind auf der linken Seite) durchsehen und eventuell verändern oder rausnehmen.

14.) Für jede Datei mit aufgelösten Konflikten „Mark Resolved“ 15.) „Commit…“ [svn commit] 16.) Kommentar angeben: „Ported rYYY from trunk.“ (YYY = in Schritt 10. gemerkte

Revisionsnummer vom Trunk!!!) 17.) „OK“ klicken

Branch in den Trunk mergen 1.) Den Trunk auschecken (siehe oben) oder falls ihr schon eine Working Copy vom

Trunk habt: „Update“ [svn update] 2.) Die Working Copy vom Trunk auswählen und „Merge…“ [svn merge] (Achtet drauf,

dass im Merge-Fenster unten bei „The result of the merge […]“ die URL des Trunks steht!)

3.) Bei „From“ als URL den Branch auswählen 4.) „Show Log“ bei „From“ anklicken 5.) Unten links in der Ecke „Stop on Copy/Move“ auswählen 6.) Revision mit kleinster Revisionsnummer auswählen und “OK” klicken 7.) Bei „To“ muss „Use ‘From’: URL” ausgewählt sein 8.) Bei „To“ als Revision „Head Revision“ auswählen 9.) „Merge“ klicken 10.) Wenn Konflikt, dann Konflikt auflösen analog zu Schritt 4. und 5. des „normalen

Arbeitsablaufs“ (die eigenen Änderungen sind diesmal rechts) 11.) Änderungen kontrollieren 12.) Für jede Datei mit aufgelösten Konflikten „Mark Resolved“ 13.) „Commit…“ [svn commit] 14.) Kommentar eingeben (z.B.: Merged branch „BranchName“ into trunk) 15.) „OK“ klicken

Will man weiter an dem Branch arbeiten, dann sollte man im Kommentar auch angeben, welche Revision gemerged wurde (d.h. welche Nummer die Head-Revision hat), ähnlich wie beim portieren von Änderungen aus dem Trunk und aus den gleichen Gründen. Will man die Änderungen dann wieder in den Trunk mergen, so muss man in Schritt 6. nicht die kleinste Revision auswählen, sondern die Revision nach dem letzten mergen.

Warum merge etwas unintuitiv ist: Merge führt einen Vergleich zwischen den beiden angegebenen Branches aus (From – To) und wendet die Änderungen auf eine Working Copy an. Intuitiv würde man vielleicht sagen: Ich vergleiche den Trunk und meinen Branch und wende die Änderungen auf meine Working Copy des Trunks an. Das ist jedoch falsch. In diesem Vergleich würden nämlich auch alle Änderungen auftauchen, die am Trunk vorgenommen wurden, die aber für den Branch nicht mehr zutreffen (z.B. weil die entsprechende Klasse nicht mehr existiert oder ähnliches). Die korrekte Weise ist die erste Revision des Branches mit der aktuellen Revision des Branches zu vergleichen und diese Änderungen auf die Working Copy des Trunks anzuwenden. Nach dem Motto: Ich habe dir am Branch gezeigt, was du ändern musst, jetzt ändere es für mich am Trunk. Analog wird dies auch bei „Änderungen vom Trunk in den Branch portieren“ gemacht.