senäh

17senäh und so…

Allgemein
29. Aug 2012
Kommentare: 0

Das Prinzip hinter Subversion a.k.a. SVN

Kategorien: Allgemein | 29. Aug 2012 | Kommentare: 0

Serie: Versionskontrolle for the rest of us

Wie ihr vielleicht schon gemerkt habt, bin ich in letzter Zeit ein großer Fan von Artikelserien. Und damit mache ich auch munter weiter. Thema diesmal: Versionsverwaltung. Ich werde die Prinzipien hinter SVN erklären und mit Beispielen anreichern. Außerdem habe ich vor, Git aus der Sicht eines SVN-Umsteigers zu betrachten. Hoffentlich kann diese Serie all jenen einen Einblick geben, die sich wohl oder übel mit der Thematik auseinandersetzen müssen. Eventuell geht aber auch dem ein oder anderen Pro noch ein Lichtlein auf, wetten würde ich darauf allerdings nicht 😉

Den Anfang macht SVN. Warum? Git ist doch der heiße Shice! Mag sein, aber SVN ist gefühlt immer noch verbreiteter. Jede IDE, die Unterstützung für Versionskontrolle mitbringt, kann hundertprozentig SVN. Git? Lediglich vielleicht. Aber Git wird immer populärer. Und das – Achtung Spoiler-Alarm – zurecht. Das wird vor allem deutlich, wenn man von SVN kommt und sich der Stärken von Git bewusst wird. Aber bleiben wir für heute bei SVN.

Wozu noch mal Versionskontrolle?

Fanatischen senäh-Lesern wird auffallen: der spricht doch nicht das erste Mal darüber. Damals habe ich es bereits beschrieben, doch im Zuge dieser Artikelserie macht es Sinn, das Thema Versionskontrolle (VK) generell noch mal zu erklären.

Der Hauptzweck von VK ist grob umfasst die Sicherung von Projektfortschritten mit optionaler Rückkehr. Kein Code soll verloren gehen, weder durch fehlendes Speichern noch durch versehentliches Überschreiben durch andere. Anders als der Name vielleicht suggerieren könnte, ist VK also viel mehr als nur das Tracken von Versionsnummern.

Das Prinzip SVN

In SVN gibt es einen zentralen Datenbestand, der quasi der Master ist. Was er sagt ist Gesetz. Von dort aus beziehen alle Projektbeteiligten ihren Code und schieben ihre Änderungen auch wieder dorthin zurück. Genannt wird das ganze Repository.

Habt ihr die glorreiche Aufgabe bekommen an einem Projekt mitzuentwickeln, das sich auf SVN als VK-System stützt, ist der grundsätzliche Workflow folgendermaßen:

  1. Ihr zieht euch eine Kopie des Codes aus dem Repository.
  2. Ihr fügt eure Änderungen ein.
  3. Sobald ein geeigneter Stand erreicht ist (dazu später mehr), teilt ihr eure Änderungen dem Repository mit.
  4. Damit die Änderungen auch den anderen Entwicklern zugänglich gemacht werden, müssen diese das Repository regelmäßig nach Veränderungen fragen.

Auf diese Art und Weise bleiben alle am Projekt beteiligten Entwickler stets auf dem selben Stand. Schauen wir uns die einzelnen Schritte im Detail an.

Schritt 1: Working Copy ziehen

Als erstes zieht ihr euch eine Arbeitskopie. Das bedeutet nichts anderes als dass der aktuelle Stand aus dem Repository in einen Ordner auf eure Festplatte überführt wird. Dabei werden außerdem einige Systemordner angelegt, die SVN dabei helfen seine Aufgabe ordentlich zu erledigen. Das fertige Konstrukt bezeichnet man dann als Working Copy.

Schritt 2: Änderungen einfügen

Fortan könnt ihr Dateien bearbeiten. Dabei müsst ihr jedoch ein paar Sachen beachten. SVN mag es nicht, wenn Dateien einfach verschwinden, die es doch gerade eben noch auf’m Schirm hatte. Dabei verhält es sich ziemlich zickig.

Beispiel: eine Datei umbenennen. Normalerweise würdet ihr Dateien einfach über einen Datei-Manager (Windows Explorer, Finder, …) umbenennen. Nicht mit SVN. Auch verschieben oder löschen sollte nicht auf dem klassischen Wege erfolgen, solang ihr euch in einer SVN-Working Copy befindet.

Warum? Fragt nicht. Ihr werdet es sowieso irgendwann merken und dann nur noch fluchen. SVN behält den Dateistatus innerhalb der angesprochenen Systemordner. Wenn beim Überprüfen eine Datei dann plötzlich nicht mehr so ist, wie SVN es erwartet, dann gnade euch Gott.

Besser gleich richtig machen. Ihr müsst SVN sagen, dass es für euch eine Datei umbennenen, verschieben oder löschen soll. Das geht entweder über die SVN-Befehle auf der Kommandozeile oder über einen GUI-Client. Vor ersterem konnte ich mich innerhalb der letzten 2 Jahre erfolgreich drücken. Ich bin ein Mann guter grafischer Interfaces. Auf konkrete Clients gehe ich allerdings erst im nächsten Teil ein, schließlich geht es hier um die Prinzipien. Konkret kommt später.

Jedenfalls könnt ihr einmal eingerichtet im Client eurer Wahl gezielt die gewünschten Dateioperationen ausführen. SVN und eure Geduld werden es euch danken.

Schritt 3: Änderungen ans Repository schicken

Sobald ihr meint eure Änderungen sind bereit für die Öffentlichkeit – oder zumindest euer Projektteam – müsst ihr sie comitten. Dabei sagt ihr dem Repository, was ihr geändert habt. Ihr könnt auch nur ausgewählte Dateien comitten, falls ihr noch nicht all eure Änderungen für reif genug haltet.

Außerdem gilt es als guter Stil euren Commit mit einer Nachricht zu versehen. So lassen sich einzelne Änderungen später schneller durchforsten, sollte dies mal nötig sein.

Doch wann sollte man comitten? Da gibt es verschiedene Philosophien.

Wichtig ist, dass ihr das Projekt bei den anderen nicht zerhaut. Auch nach eurem Commit sollten eure Teammates noch fähig sein, die Applikation, Webseite oder was auch immer genauso benutzen zu können wie vorher.

Andere wiederum verbreiten militant den Schlachtruf commit early, commit often. Vorteil: viele kleine Änderungen sind leichter nachzuvollziehen als eine Große. Nachteil: ihr seid früher oder später gezwungen auch halbfertige Bugfixes und Feature-Implementierungen zu comitten.

Gut lösen lässt sich sowas über Branches, eine Art parallele Entwicklungsstränge. Doch das ist für den Anfang vielleicht etwas zu kompliziert.

Am besten sprecht ihr diesbezügich einfach mit eurem Projektteam. Wie so oft gilt auch hier, dass weniger wichtig ist, welchem Prinzip man folgt, sondern dass man es konsequent anwendet.

Schritt 4: Update

Damit ihr regelmäßig die Änderungen eurer motivierten Mitentwickler zu Gesicht bekommt, müsst ihr eure Working Copy updaten. Was dabei passiert? Das Repository wird nach Änderungen seit dem letzten Updaten befragt. Sollte es solche geben, werden diese übermittelt. SVN versucht dabei intelligent zu sein und überschreibt die betroffenen Dateien nicht einfach, sondern pflegt die Veränderungen in eure Working Copy ein. Dadurch wird es möglich, dass 2 Entwickler Veränderungen an der selben Datei durchführen, sich dabei aber gegenseitig nicht die Dateien überschreiben. Dieser Vorgang wird als Mergen bezeichnet. Man könnte auch synchronisieren sagen.

Eigentlich – dem SVN-Nerd wird es schon aufgefallen sein – ist die hier angegebene Reihenfolge sogar falsch. Vor jedem Commit muss ein Update durchgeführt werden. Ihr müsst erst die zwischenzeitlichen Änderungen in eure Working Copy mergen, ehe ihr Änderungen an das Repository senden könnt.

Warum? Ganz einfach: hin und wieder kann es doch passieren, dass SVN es nicht schafft Änderungen von 2 Seiten an einer Datei korrekt aufzulösen. Man spricht dabei von Konflikten. Und diese müssen gelöst werden, damit ihr sie nicht auf das Repository und somit auf alle anderen Entwickler übertragt.

Konflikte

Wie bereits erwähnt treten Konflikte auf, wenn 2 Entwickler eine Datei an ein und derselben Stelle verändern. SVN möchte keinen der beiden Entwickler bevorzugen oder benachteiligen, weswegen es auf einen Konflikt in dieser Datei hinweist. Es ist die Aufgabe des Entwicklerteams diesen zu lösen.

Wann genau treten Konflikte jetzt auf? Sobald du deine Working Copy verändert hast, diese Veränderungen commiten willst, vorher aber noch brav dein Update ziehst. Es kann passieren, dass ein Mitentwickler an derselben Stelle Code verändert hat. Und jetzt liegt es an dir zu sagen, welcher von euch beiden Recht hat.

Wie das konkret aussieht, darauf gehe ich im nächsten Teil ein. Zum jetzigen Zeitpunkt müsst ihr euch nur bewusst sein, dass Konflikte auftreten, von SVN als solche markiert und von euch beseitigt werden müssen.

Übrigens habe ich mal gelesen, dass Konflikte nur bei schlechter Aufgabenverteilung auftreten, da jeder Entwickler seinen abgegrenzten Bereich haben sollte. Klingt auch logisch. Meine Praxis zeigt, dass Konflikte in der Regel “aus Versehen” entstehen. 2 Entwickler haben gleichzeitig einen Bug gefixed oder eine Konfigurationsdatei verändert. Was ich damit sagen will: ihr werdet auf Konflikte treffen und es fühlt sich immer nervig an. Jedoch sollte es eigentlich nicht allzu oft passieren. Und das Fixen geht in 90% der Fälle recht schnell von der Hand.

Lessons Learned

Ihr habt gelernt, wozu SVN da ist und wie es euch helfen kann. Ihr wisst, dass ein Repository die zentrale Sammelstelle für den Code eines Projekts ist. Die 3 Hauptoperationen im SVN sind checkout, update und commit. checkout erzeugt eine Arbeitskopie aus dem Repository, update versorgt euch mit Code-Aktualisierungen anderer Entwickler und commit sendet eure eigenen. Ihr wisst nun außerdem, dass Konflikte auftreten, wenn 2 Entwickler dieselbe(n) Zeile(n) einer Datei bearbeiten. Und was ganz wichtig ist: Dateien niemals per Hand umbenennen, verschieben oder löschen. Das überlassen wir SVN!

Im nächsten Teil geht es weiter mit konkreten Beispielen, der der trockenen Theorie etwas Leben einhauchen dürften. Außerdem erfahrt ihr etwas zu brauchbaren Clients und wie ihr selbst an ein SVN-Repository kommt. Bis dahin 🙂

Autor: Enno

Ich bin Enno. PHP ist mein Ding, aber auch alles Neue rund um die Themen HTML5, CSS3 & Co finde ich interessant. Ich mag es Leuten zu helfen und mein Wissen weiterzugeben. Sollte dir mein Beitrag gefallen haben, lass doch nen Kommentar da oder benutze einen der Social Buttons, um deinen Dank auszudrücken ;)