SVN: Aus Alt mach Neu

Um das Jahr 2000 nutzten freie Softwareprojekte beinahe ausschließlich CVS – allerdings in erster Linie mangels freier Alternativen. Die Einschränkung, Dateien nicht ohne Verlust der Historie verschieben zu können, erschwert schließlich ein Refactoring. Ab 2005 verdrängte daher Subversion (SVN, [2]), mit dem dies möglich ist, den bisherigen Platzhirsch CVS innerhalb weniger Jahre.

SVN übernimmt die zentralen Funktionen und den Wortlaut der Befehle wie »checkin« , »checkout« oder »update« . Versteckt hinter dieser Konstanz an der Oberfläche verändert es jedoch das Prinzip der Versionierung: Subversion führt nicht mehr über einzelne Dateien Buch, sondern es legt für jeden Commit durchnummerierte Snapshots des ganzen Repository an. Auch das Umbenennen oder Verschieben von Dateien funktioniert nun problemlos. Die Versionshistorie erfasst auch Verzeichnisnamen und symbolische Links.

Außerdem geht Subversion geschickter mit binären Dateien um als CVS, das sich beim Erkennen ausschließlich auf die Endung verlässt und daher leicht Dateien zerstört. Subversion benutzt dagegen eine Heuristik, die auf dem Vorkommen von Nullbytes und der Zahl nicht druckbarer Zeichen basiert. Last but not least sind bei SVN Commits atomar, kommen also entweder ganz oder gar nicht im Repository an.

Verteilte Systeme

Alle Änderungen in ein zentrales Code-Repository einzuchecken ist ein gangbarer Weg für kleinere Teams. Jedes Mitglied sieht dabei die Änderungen aller Kollegen und richtet seine Arbeit danach aus. Bei großen Projekten wie dem Linux-Kernel sind dagegen Elemente aus demselben Subsystem eng aneinandergekoppelt, Module für ein Dateisystem und der Treiber für eine Webcam dagegen kaum. Wegen der schieren Anzahl der Commits ist hier das Einrichten von Unterrepositorys überlebenswichtig. Schließlich müssen aber trotzdem alle für gut befunden Änderungen den Weg in den zentralen Codebaum von Linus Torvalds finden.

Verteilte Versionskontrollsysteme wie die hier vorgestellten Programme Git [3], Mercurial [4] und Bazaar [5] bieten dafür die richtige Infrastruktur: »pull« -Requests holen die Änderungen eines anderen Entwicklers in den eigenen Codebaum, »push« überträgt sie aus dem eigenen Repository in ein fremdes. Die Codebäume aller Entwickler dienen also ohne feste Hierarchie als Daten-Quellen oder -Empfänger (Abbildung 1).

Abbildung 1: Anders als beim klassischen Verfahren (links) laufen bei verteilten Revisionskontrollsystemen (rechts) nicht mehr alle Fäden auf einem zentralen Server zusammen. Vielmehr kommunizieren Team-Mitglieder in erster Linie mit denen, deren Änderungen sie interessieren.

Bei verteilen Versionskontrollsystemen sind lokale Check-ins auch ohne Netzanbindung möglich. Da jeder Check-out seine eigene Versionsgeschichte schreibt, lassen sich Branches am einfachsten durch Klonen eines lokalen Repository erzeugen. Alternativ beherrschen die drei vorgestellten Systeme auch das Branchen innerhalb eines Repository.

Eigenständige Repositorys kosten im Vergleich zu Repository-internen Branches mehr Rechnerressourcen, da sie nicht nur die Arbeitsdateien, sondern auch die Versionshistorie duplizieren. Da die Versionskontrollsysteme bei lokalen Klonen – soweit möglich – Hardlinks nutzen, fällt dies aber nur bei sehr großen Projekten ins Gewicht.