Warum Entwickler begeistert von verteilten Versionsverwaltungssystemen sind

Wenn Entwickler über Versionsverwaltung sprechen, dann beschweren sie sich meistens, speziell über einige ältere Systeme, die auslaufen, nicht mehr unterstützt und schnell verschwinden werden. Wenn nun Entwickler, die man kennt und achtet, sich darüber unterhalten, wie sehr sie ihre verteilten Versionsverwaltungssysteme (Distributed Version Control System, DVCS) mögen, sollte man aufhorchen. Auf der Grundlage von Untersuchungen zu DVCS soll nun dargestellt werden, wodurch sich diese Systeme von herkömmlichen Versionsverwaltungssystemen unterscheiden und warum viele Entwickler DVCS bevorzugen.

Was DVCS unterscheidet

Der grundlegende Unterschied zwischen DVCS und herkömmlicher Versionsverwaltung liegt darin, wo sich das Repository befindet. Bei herkömmlichen Versionsverwaltungssystemen gibt es ein zentrales Repository, das möglicherweise aus Performance- und Redundanzgründen auf wenige Knoten gespiegelt wird und die Master-Kopie jeder Datei enthält. Entwickler haben eigene Kopien auf ihren lokalen Laufwerken, und wenn ein Anwender seine Kopie zum Master machen möchte, muss er sie wieder einchecken. Anwender können Dateien im Repository sperren, um zu signalisieren, dass die Datei geändert wird, und wenn eine Datei ins Repository eingecheckt wird, müssen alle Unterschiede zwischen dem, was auf dem Server ist, und dem, was eingecheckt wird, aufgelöst werden, wenn die Dateien separat von verschiedenen Anwendern geändert wurden. Wenn man eine andere Version ausprobieren oder erstellen möchte, zweigt man den Codebaum ab, wodurch eine völlig andere Fassung entsteht. Später kann man die beiden Bäume wieder zusammenführen, doch muss man dann die Unterschiede zwischen beiden auflösen.

Ein DVCS dreht die Sache um. Statt eines zentralen Repositorys auf einem zentralen Server hat jeder Entwickler seine eigenen Repositories (wodurch das Ganze eben zu einem „verteilten“ System wird). Es ist einem Peer-to-Peer-Netzwerk sehr ähnlich. Dadurch entsteht viel mehr Redundanz als bei einem herkömmlichen Versionsverwaltungssystem. An und für sich ist das nichts Besonderes. Der große Unterschied liegt im Check-in-Verfahren. DVCS arbeitet mit Change Sets, Änderungsbeschreibungen, und erzeugt eines bei jedem Einchecken, wohingegen herkömmliche Systeme einfach die Datei ersetzen und ihr eine neue Versionsnummer geben. Wenn zwei Entwickler Änderungen vornehmen, die auf demselben übergeordneten Verzeichnis im Baum basieren, werden dadurch automatisch zwei parallele Zweige geschaffen.

Die Zusammenführung gegenüber herkömmlichen Systemen wird einfacher, weil das System weiß, wo die Unterschiede zwischen den beiden Zweigen liegen.Im Mercurial-Wiki gibt es eine ausgezeichnete Anleitung zu diesem Thema, die das Verfahren ausführlich erklärt.

Wo DVCS glänzt

Im Zusammenhang mit DVCS werden zwei große Vorteile genannt: die Tatsache, dass die Dinge verteilt sind, und der Arbeitsablauf. Der Aspekt der Verteilung ist für geographisch verstreute Teams, lose organisierte Teams, hochgradig mobile Teams und andere Szenarien besonder geeignet, wenn nicht jeder ständig mit einem zentralen Repository verbunden ist. Doch, wie Joel Spolsky sagte, ist es das Abzweigen und Zusammenführen, das viel interessanter ist, und nach dem, was über DVCS zu lesen ist, kann man hier nur zustimmen.

Aufgrund des Wesens von Change Sets ist es viel einfacher, die Änderungen von jemand anderem mit seinen eigenen zusammenzuführen, weil man nicht versucht, seine eigenen Änderungen und dessen Änderungen mit einem zentralen Zweig zusammenzuführen – man kann stattdessen einfach die Änderungen, die der andere vorgenommen hat, bekommen. Dadurch wird es viel einfacher zu experimentieren, verschiedene Proof-of-Concept-, Produktions- oder Qualitätssicherungsversionen zu erstellen usw. Und wenn diese Aufgaben leichter werden, werden sie auch öfter durchgeführt.

Wer einige Jahre lang Team Foundation Server (TFS) genutzt hat, wird das Zusammenführen verschiedener Versionen hassen. Es ist wirklich schade, wenn man gelernt hat, nicht abzuzweigen, und wenn dann mehrere Entwickler begannen, am selben Projekt zu arbeiten, ergaben sich immer größere Schwierigkeiten. Es ist definitiv klar, warum DVCS von großem Vorteil ist, wenn man in großen Teams und mit zahlreichen Teilen arbeitet, die hin- und herbewegt werden, denn jede Gruppe kann an ihrem eigenen Teil des Systems arbeiten und es problemlos wieder in das Projektrepository zurückführen, wenn ihre Änderungen soweit fertig sind, dass andere sie sehen sollen.

Pläne für Experimente mit DVCS

TFS ist frustrierend. Ist es ein schlechtes Werkzeug? Keineswegs. TFS bietet eine Menge eingebauter Funktionen, wie zum Beispiel die Möglichkeit, Arbeitselemente zu Check-ins zu verbinden, gute Reporting-Funktionen und Build-Management. Aber es ist wirklich miserabel für die Versionsverwaltung. Mindestens einmal die Woche hat jemand aus dem Team eine Frage zu TFS, und es handelt sich dann nicht um Anwenderfehler, sondern ist auf die Komplexität von TFS und das nicht intuitive Überarbeitungsmodell zurückzuführen.

Es ist Zeit für Veränderung. So kann man bei eigenen Projekten entweder mit Git oder mit Mercurial experimentieren, und wenn sich das bezahlt macht, kann man prüfen, ob man es für seine Arbeit übernimmt. Die Ergebnisse und Kommentare einer Umfrage von TechRepublic über Versionsverwaltung weisen darauf hin, dass viele ebenso denken.