© mch67, 123RF.com

Einst gab es in der freien Softwarewelt nur CVS. Inzwischen existieren mit Subversion, Git, Mercurial und Bazaar mehrere professionelle, ausgereifte Systeme für die Versionsverwaltung. Besonders die verteilten Versionskontrollsysteme liefern sich bei den Features ein Kopf-an-Kopf-Rennen.

Größere Softwareprojekte lassen sich nicht ohne Versionskontrollsystem bewältigen. Nur mit dessen Hilfe bleibt nachvollziehbar, wer wann welche Änderung vorgenommen hat und aus welchem Grund. Der einstigen Monokultur von CVS ist die freie Softwarewelt entwachsen: Um die Gunst der Anwender buhlen zahlreiche freie Systeme wie Subversion, Git, Mercurial und Bazaar, deren Stärken und Schwächen dieser Artikel vorstellt.

CVS: Der Urahn

CVS [1] erreichte bereits vor 20 Jahren Version 1.0. Der Veteran ermöglichte es, viele Dateien in einer gemeinsamen Versionshistorie zu verwalten, daher auch der Name Concurrent Versions System (concurrent bedeutet simultan). Damit standen jene Kernfunktionen zur Verfügung, die Entwickler bis heute bei der täglichen Arbeit mit Versionskontrollsystemen einsetzen.

Auch wenn CVS über viele Jahre wegen seiner GPL-Lizenz das verbreitetste Sourcecode-Managementsystem im Open-Source-Bereich war, so plagt es seine Anwender doch mit Unzulänglichkeiten. Sie ergeben sich größtenteils daraus, dass CVS auf einer Versionsverwaltung für einzelne Dateien aufsetzt.

In der Software-Entwicklung beschränkt sich ein logischer Entwicklungsschritt, den der Entwickler in einem Commit zusammenfasst, oft nicht auf eine einzige Datei. Bei CVS lassen sich zusammengehörige Revisionen mehrerer Dateien nur über Commit-Zeitpunkt und -Message in Beziehung setzen. Eine Revisionsnummer kennzeichnet nur die Zahl der Änderungen an einer einzelnen Datei.

Dass CVS isoliert über einzelne Dateien Buch führt statt Snapshots des ganzen Repository anzulegen, bringt noch weitere Einschränkungen mit sich: Beim Verschieben oder Umbenennen von Dateien im Repository verlieren diese ihre Versionshistorie. Außerdem verlaufen Commits in CVS nicht atomar: Das System iteriert bei einem Commit über die Ordner eines Repository und sperrt dabei nur das Verzeichnis, mit dem es gerade beschäftigt ist.

Atomzeitalter

Netzwerkprobleme oder zwei gleichzeitig laufende Übertragungen versetzen das Repository daher unter Umständen in einen inkonsistenten Zustand – allerdings nur was den Inhalt des letzten Commit angeht. Gegen die Korruption der Datenstrukturen, die das ganze Repository unbrauchbar machen, ist das einfach gestrickte CVS, das jeder Quellcode-Datei in einem Unterverzeichnis eine Datei mit gesonderter Versionshistorie zuweist, sehr resistent. CVS erfährt nur noch eingeschränkten Support, neue Features wird es nicht mehr geben.

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.

Ganz informell

Bei der Arbeit mit einem gemeinsamen Repository ist es üblich, dass jeder Entwickler seinen Code vor dem Einchecken zumindest elementaren Qualitätstests unterziehen muss. Versionen im Hauptzweig, die sich nicht kompilieren lassen, erschweren schließlich die Arbeit aller Team-Mitglieder. Branches sind der einzige Ausweg, doch die müssen die Entwickler vor Beginn eines Arbeitsschritts anlegen und im Team ankündigen. In der Praxis wachsen Commits dadurch oft zu einer Größe an, die das Eingrenzen von Fehlern im Code erschwert.

Die verteilte Repository-Struktur ermöglicht andere Arbeitsweisen. So kann Harry, dem beispielsweise erst nach dem Meeting einfällt, dass er Sallys neuen Filter gegen SQL-Injection für seine Arbeit an der neuen Eingabemaske benötigt, sich den aktuellen Zwischenstand mit einem Pull direkt aus Sallys persönlichem Repository besorgen.

Merges machen Mühe

Der organisatorische Aufwand beim Einrichten von Seitenzweigen ist aber nicht der Hauptgrund, warum bei der Arbeit mit SVN oder CVS meist die Devise gilt: Branches wenn möglich vermeiden. Am meisten schreckt der schlecht funktionierende Merge-Algorithmus ab, der das Einpflegen der Änderungen von parallelen Zweigen in den Hauptstrang zu einer unangenehmen, zeitraubenden und fehlerträchtigen Aufgabe macht.

Git, Mercurial und Bazaar versprechen das Mergen gegenüber CVS und SVN zu erleichtern. Sie speichern bei jeder Verzweigung des Codebaums das Elternelement und kalkulieren so bei einem Dreiwege-Merge zuverlässig die richtige Basis. Sie merken sich außerdem die in Vorgängerversionen durchgeführten Merges und vermeiden so Konflikte, die sich aus einem wiederholten Einpflegen derselben Änderung ergeben.

Statt »svn merge -r 1243:1376 file:///Pfad/zum/Branch« genügt zum Beispiel bei Git »git merge Pfad/zum/Repository« . Das System kennt den Zeitpunkt der Abspaltung des Zweigs und errechnet selbst die richtigen Revisionsnummern. SVN 1.50 hat hier allerdings schon im Juni 2008 nachgebessert und den Aufwand beim Branching und Merging reduziert.

Nach Meinung vieler sind es aber nicht die verbesserten Algorithmen, die Linus Torvalds’ Forderung “Merges sollten schmerzfrei über die Bühne gehen” [6] einlösen. Charakteristisch für verteilte Versionskontrollsysteme ist vielmehr, dass Entwickler regelmäßig die Arbeit der Teamkollegen, die an verwandten Problemstellungen arbeiten, in die eigene Arbeitskopie einpflegen (Abbildung 1). Die meisten Konflikte lassen sich daher bereits in kleiner Runde lange vor dem Sammeln des Code für die nächste Release ausräumen.

Last but not least spielt es eine Rolle, dass Merge-Operationen lokal und daher besonders beim in C geschriebenen Git sehr schnell über die Bühne gehen. Linus Torvalds überschlägt in seinem Vortrag [6], dass dagegen ein Merge seines Codebaums mit dem von Andrew Morton mit klassischen Versionsverwaltungssystemen mehrere Stunden dauern würde – eine echte Geduldsprobe, da der Entwickler Merges wegen möglicher Konflikte beaufsichtigen muss.

Git: Der Gipfelstürmer

Merges sind einer der Prüfsteine, an denen Versionskontrollsysteme ihre Qualität unter Beweis stellen. Einen ersten Einblick in die Leistungsfähigkeit von Git gibt die Manpage zu »git-merge« . So bietet Git die Wahl zwischen fünf unterschiedlichen Merge-Strategien.

Der Standard-Merge-Algorithmus »recursive« , der eine mehrgliedrige Vererbungsgeschichte durch mehrere, die Historie nachzeichnende Dreiwege-Merges auflöst, hat sich in der Kernelentwicklung als bester Kompromiss zwischen vermeidbaren Konflikten und fehlerhaften Merges ergeben. Er akzeptiert außerdem die Parameter »ours« und »theirs« , die im Konfliktfall ohne Nachfrage die eigene oder die fremde Lösung präferieren.

Bei verteilten Versionskontrollsystemen ist es üblich, dass sich der letzte lokale Commit, der das private Repository noch nicht verlassen hat, zurücknehmen lässt, um etwa Tippfehler in der Commit Message zu korrigieren oder vergessene Dateien hinzuzufügen. Git geht hier einen Schritt weiter: Der Anwender darf beliebig weit zurückliegenden Commits editieren, solange er sie noch nicht per »pull« in ein anderes Repository übertragen hat.

Einerseits bricht Git hier mit dem ehernen Gesetz der Versionskontrolle, dass jede Aktion nachvollziehbar bleiben und sich bei Bedarf rückgängig machen lassen soll. Andererseits führt die nachträglich fälschbare Commit History das Prinzip der zunächst privaten Revisionen bei der verteilten Versionsverwaltung konsequent zu Ende.

Klassenprimus

Git bietet Entwicklern jedes nur erdenkliche Feature. Wegen seiner großen Verbreitung sind zudem zahlreiche externe GUI-Projekte entstanden [7]. Einen in Tcl/Tk geschriebenen Tree-Browser liefern die Git-Entwickler selber mit. Unter den unabhängigen Projekten besonders hervorzuheben ist Git-Cola, das fast alle Git-Funktionen unterstützt, beim Tree-Browser aber auf das optisch altbackene Gitk setzt. Auch das mitgelieferte Webfrontend Gitweb, das Kernel.org benutzt, ist optisch und beim Funktionsumfang keine Offenbarung. Doch gibt es zahlreiche Alternativen, die in fast allen in der Webentwicklung üblichen Programmiersprachen umgesetzt sind [7].

Git lässt sich in Netbeans und Eclipse einbinden. Auch für die freie Projektmanagement-Software Trac gibt es ein Plugin. Ebenso gut sorgt das Git-Wiki für Vi- und Emacs-Anwender.

Mercurial: Die goldene Mitte

Der Umstieg zwischen Mercurial und Git gleicht in einem Punkt dem zwischen SVN und CVS: Bei allen grundlegenden Befehlen ersetzt der Anwender lediglich »git« durch »hg« . Zwar ist Mercurial überwiegend in Python und nicht in C programmiert, dennoch ähneln sich Repository-Struktur und funktionale Prinzipien stark. Viele Git-Plugins, zum Beispiel die für Netbeans und Trac (Tabelle 1) sind Forks des Mercurial-Plugin.

Auch Linus Torvalds nennt Mercurial in seinem Vortrag über Git [6] eine im Wesentlichen gleichwertige Lösung. Wegen seiner Python-Basis lässt sich Mercurial effizienter unter Windows nutzen, während Git dort auf die Cygwin-Umgebung [8] angewiesen ist und unter Performance-Einbußen leidet. Seit einiger Zeit gibt es allerdings auch eine native Windows-Version [9].

Im Lieferzustand besticht Mercurial durch einen handlichen, für die meisten Anwender völlig ausreichenden Feature-Umfang, der zudem systematisch und verständlich dokumentiert ist [10]. Gits sehr großer Leistungsumfang dagegen schreckt Einsteiger eher ab.

Ohne Erweiterungen gibt sich Mercurial bezüglich der History unbestechlich. Es ist – abgesehen von dem auch hier mit »rollback« revidierbaren letzten Commit – nicht möglich, ins Repository übertragene Dateien oder Changesets aus der Historie zu tilgen.

Transplantation

Mercurial enthält aber bereits im Lieferumfang Erweiterungen fürs Abändern der History, die man nur in der Konfigurationsdatei aktivieren muss. Mit der Transplant-Erweiterung [11] sind, wie der Name andeutet, Changesets zu verpflanzen. Der häufigste Anwendungsfall ist das von Git bekannte Rebasing, das die Changesets eines Branch in den Hauptzweig überträgt, als hätte der Entwickler sie direkt dort eingecheckt. Die Transplant-Extension unterstützt wie Git das Cherry Picking, also das Rauspicken von Revisionen (Abbildung 2).

Abbildung 2: Das partielle Mergen bestimmter Revisionen nennen Entwickler bildhaft Cherry Picking. Sowohl Git als auch Mercurial und Bazaar unterstützen dieses wählerische Herauspicken von Änderungen.

Der Preis für die in verteilten Revisionskontrollsystemen über Repository-Klone leicht erzeugbare mehrsträngige Revisions-History ist der Verzicht auf die fortlaufende Nummerierung der Versionen. Schließlich führen in einem verzweigten Baum Pfade mit unterschiedlicher Knotenzahl zum gleichen Commit. Git, Mercurial und Bazaar benutzen daher eindeutige Hashes, um Revisionen zu identifizieren.

Die unhandlichen Hashes darf der Anwender dabei abkürzen, solange sie eindeutig bleiben. Git bietet als Ersatz für durchlaufende Nummerierung die Notation »~3« , um in Befehlen auf die drittletzte Revision zu verweisen. Mercurial weist Check-ins zusätzlich zum eindeutigen Hash eine fortlaufende Nummer zu, die allerdings nur für ein bestimmtes Repository gilt und daher zu Missverständnissen führen kann.

Wie bei Git gibt es Mercurial-Plugins für die IDEs Eclipse und Netbeans, die jedoch etwas ausgereifter wirken als ihre Git-Pendants. Von der Windows-Software Tortoisehg [12] gibt es eine Linux-Variante, die sich in den Gnome-Dateimanager einklinkt (Abbildung 3). Wie Git bringt auch Mercurial ein einfaches Webfrontend mit, das immerhin einen Diff-Viewer mit Syntax Highlighting bietet. Auch Vi- und Emacs-Anhänger werden im Mercurial-Wiki fündig [13].

Abbildung 3: Tortoisehg, das sich in Namen und Aufbau an das bekannteste Windows-Frontend für SVN anlehnt, bietet unter Linux neben der Eclipse- und Netbeans-Anbindung die beste grafische Oberfläche für Mercurial.

Bazaar: Canonicals Sonderweg

Git und Mercurial entstanden beide Anfang 2005, als Bitmover die kostenlose Lizenz seiner Software Bitkeeper für den Linux-Kernel widerrief. Die Arbeit an Bazaar begann wenige Monate früher und übernahm den Namen des GNU-Arch-Fork, mit dem Canonical bis zu diesem Zeitpunkt arbeitete.

Sehr offensiv nennt die Dokumentation “die zehn wichtigsten Gründe für den Umstieg”. Doch zeigt sich schon auf den ersten Blick, dass die meisten zumindest im Vergleich mit anderen verteilten Versionskontrollsystem nicht greifen. Insgesamt bleiben im Vergleich mit Git und Mercurial dennoch Besonderheiten: Das ebenfalls in Python geschriebene Bazaar unterstützt wie Mercurial Windows ausgezeichnet und es integriert ein vom Bazaar-Team entwickeltes, sehr leistungsfähiges GUI (Abbildung 4).

Abbildung 4: Der Bazaar Explorer bietet ein vollständiges und dennoch übersichtliches GUI für Canonicals Versionsverwaltung. Dank Qt-Basis steht er auch für Windows und Mac OS X zur Verfügung.

Workflows

Doch der Anspruch von Bazaar, als einziges System unterschiedliche Workflows zu unterstützen, lässt sich nicht halten. Jedes verteilte Versionsverwaltungssystem erlaubt auch das Publizieren in ein zentrales Repository. Zwar erlaubt es nur Bazaar, auf eine lokale Versionshistorie ganz zu verzichten, sodass ein Check-in die Daten direkt an den Server überträgt. Doch abgesehen davon, dass es dem Entwickler den Aufruf von »pull« nach dem Check-in erspart und weniger Plattenplatz braucht, bringt Bazaars Besonderheit während der Entwicklung keine Vorteile. Die vollständig lokal vorliegende History, die unter anderem schnelle lokale Merges ermöglicht, gilt schließlich als der wesentliche Fortschritt verteilter Systeme gegenüber SVN und CVS.

Als praktisch erweisen sich die so genannten leichtgewichtigen Check-outs dagegen bei der Webentwicklung, wo sie beim Auschecken direkt auf dem Server Plattenplatz und Netzbandbreite sparen. Doch dies gilt auch für einen lokalen Mercurial- oder Git-Check-out mit nachfolgendem Rsync zum Server, der das ».mercurial/« oder ».git/« -Verzeichnis ausspart. Beide Systeme verteilen – anders als CVS und SVN – die Versionsdaten ja nicht über alle Unterverzeichnisse.

Für jedermann?

Unterm Strich ist Bazaar nicht einfacher zu bedienen als Mercurial oder Git. Wenn Bazaar seinen Anspruch “Versionskontrolle für jedermann” einlösen kann, dann wegen des mitgelieferten umfangreichen GUI, des Bazaar Explorer, der den gesamten Funktionsumfang von Bazaar unterstützt und sogar einen übersichtlichen Diff-Viewer enthält. Außerdem existiert ein Eclipse-Plugin [14].

Das Netbeans-Plugin [15] befindet sich noch ein einem relativ frühen Entwicklungsstadium. Dies gilt auch für das Trac-Plugin [16]. Ausgereift ist dagegen die Anbindung an die ebenfalls von Canonical entwickelten Launchpad-Plattform. Loggerhead [17], das leistungsfähige Bazaar-Webfrontend aus der Launchpad-Software, ist auch als separate Anwendung erhältlich.

Zahlenspiele

Bazaar stellt ebenso wie Mercurial den unhandlichen Revisions-Hashes fortlaufende Nummern zur Seite. Auch bei Bazaar können diese in verschiedenen Repositorys divergieren. Beim Einsatz des Merge-Kommandos löst Bazaar das Problem allerdings durch Anhängen eines Dezimalpunkts. Treffen die privaten Revisionen 124 von Harry und Sally in einem Merge aufeinander, nummeriert Bazaar sie als 124.1.1 und 124.2.1. Leider verändert ein Rebase die Revisionsnummern, sodass sie sich nur dann zur eindeutigen Identifizierung eignen, wenn ein Team auf diese bei Git-Anwendern beliebte Technik verzichtet, um private Branches in den zentralen Codebaum einzubinden.

Als kleiner Vorteil erweist sich bei Webanwendungen, dass Bazaar im Unterschied zu Git und Mercurial auch leere Verzeichnisse speichert. So erzeugt ein Check-out beispielsweise Cache-Verzeichnisse auch ohne Workarounds wie Dummy-Dateien, die nur dort liegen, damit die Versionsverwaltung die Ordner erfasst.

Ein gewichtiger Pluspunkt ist auf jeden Fall die Dokumentation [18], die noch umfangreicher und anfängerfreundlicher ausfällt als bei Mercurial. Wie Git unterstützt Bazaar außerdem mehrere Merge-Algorithmen, was unter Umständen bei sich kreuzenden Vererbungslinien Konflikte erspart. Auch Rebasing und Cherry Picking erlaubt Canonicals Software.

Qual der Wahl

Die einzige klar erkennbare Trennungslinie verläuft bei den Versionskontrollsystemen zwischen CVS und SVN mit ihrem verpflichtenden zentralen Repository einerseits und den verteilten Systemen Git, Mercurial und Bazaar. Nur wer größtes Gewicht darauf legt, dass die Entwickler alle Check-ins ohne Verzögerung auf dem zentralen Server veröffentlichen, wird nach wie vor die ältere, Server-basierte Architektur bevorzugen.

Die dezentrale Organisation bringt viele Vorteile, die Git, Mercurial und Bazaar teilen: Merges laufen lokal schnell ab. Mögliche Konflikte zwischen Versionen kommen nicht erst im zentralen Repository zutage, vielmehr kommunizieren an verwandten Problemstellungen arbeitende Entwickler bei Bedarf spontan, ohne vorher auf dem Server Branches einzurichten.

Git bietet den größten Leistungsumfang, den Mercurial allerdings mehr und mehr mit Erweiterungen nachbildet. Für Git spricht zudem die größere Verbreitung: Schon der Kernel mit seiner riesigen Codebasis und dem großen, inhomogenen Entwicklerteam bürgt für seine Leistungsfähigkeit. Mercurial ist dagegen die von Google präferierte Lösung, die sich auch unter Windows wacker schlägt. Auch große Firmen wie Mozilla setzen auf das wie Git von einem Linux-Kernelentwickler initiierte Projekt.

Zwar abgeschlagen in puncto Verbreitung, aber in der Gesamtwertung landet Bazaar keineswegs auf dem letzten Platz. Es punktet dadurch, dass es leistungsfähige Merge-Algorithmen mit Windows-Kompatibilität und einem leistungsfähigen GUI kombiniert.