Über den Status quo verteilter Versionsverwaltungssysteme
Seite 2: Verteilte Welt
Verteilte Welt
Allen drei Systemen ist gleich, dass sie keinen zentralen Server benötigen, sondern nach dem Peer-to-Peer-Konzept arbeiten. Das bedeutet, dass auf jedem Peer ein Repository existiert, das eine Teilmenge aller Entwicklungszweige enthält. Es gibt aber nicht zwingend ein Repository, in dem alle Änderungen vorhanden sind. Jeder Benutzer entscheidet selbst, welche Änderungen er in sein Repository aufnimmt. In jedem Repository ist die Änderungshistorie der Artefakte enthalten, sodass hierdurch inhärent Backups vorliegen, vorausgesetzt, die Änderungen wurden bereits verteilt.
Das erscheint einem Betrachter, der aus der "alten Welt" der klassischen Versionsverwaltungssysteme kommt, recht chaotisch. Aber das Konzept ist weit von einem Chaos entfernt, denn alle Vorgänge sind nachvollziehbar.
Ein klarer Vorteil zeichnet sich ab, wenn es um die Geschwindigkeit und Arbeitsweise geht: Ein Entwickler ist unabhängig von einer Netzverbindung, sobald er ein lokales Repository hat. Auch in Zeiten von UMTS und fast flächendeckender Breitbandanbindung kommt es häufig genug vor, dass keine Netzverbindung besteht. Zwar ist auch ein Subversion-Nutzer nicht immer auf eine Netzverbindung angewiesen, aber sobald es darum geht, sich die Historie einer Datei im Detail anzuschauen, gestaltet sich die Arbeit mit dem Werkzeug schwierig. Ein Commit schließt sich damit verständlicherweise ganz aus. Nun mögen Kritiker anmerken, dass ein Commit in einem DVCS nicht ganz gleichzusetzen ist mit einem Commit im Kontext eines Versionskontrollsystems mit zentralem Server. Der Einwand ist nicht unberechtigt, da die Daten letztlich immer noch "nur" lokal vorliegen und zu verteilen sind, zudem existiert dadurch kein Backup der Daten. Aber es findet durch den Einsatz von Peer-to-Peer-Konzepten eine sinnvolle Entkoppelung statt.
Vollig losgelöst
Wie erfolgt nun die Synchronisation der Änderungen unter den Entwicklern, da verteilte Versionsverwaltungssysteme keinen zentralen Server benötigen? Das erfolgt nach dem Pull-und-Push-Prinzip. Ein Benutzer kann seine Änderungen, die er über ein Commit aus der Arbeitskopie in sein lokales Repository aufgenommen hat, in ein anderes Repository über einen Push übermitteln. Möchte der Benutzer Änderungen von einem anderen in sein lokales Repository ziehen, führt er einen "Pull" aus.
Möchte ein Projekt partout ein zentrales Repository einsetzen, steht diesem trotz allem "Verteilen" nichts entgegen: Sowohl Git als auch Mercurial bieten Funktionen an, einen eigenen Webserver zu starten oder eine Webserver-Installation zu nutzen. Ein schönes Beispiel ist hierfür der Server des Linux-Kernel-Projekts , aus dem heraus sich Torvalds die Snapshots für den nächsten Kernel in sein lokales Repository holt. Auch lassen sich Protokolle wie ssh für den Austausch der Daten einsetzen. Um das Ganze abzurunden, können Entwickler über E-Mails Changesets austauschen.
Das dezentrale Vorgehen führt dazu, dass fortlaufende Revisionsnummern wie bei Subversion nicht ausreichen. Git verwendet daher als Revisionsnummer einen SHA1-Hash, Mercurial eine Kombination aus einer lokalen und einer globalen Revisionsnummer, wobei Letztere ebenfalls ein SHA1-Hash ist.
Auf Basis der Revisionsnummern und des Verfolgens aller Branches und Merges können sowohl Mercurial als auch Git feststellen, welche Änderungen bereits von einem Branch in einen anderen oder den Hauptentwicklungszweig überführt wurden. Mehrfache Merges aus einem Branch heraus sind dadurch fast zu einem Kinderspiel geworden. Konflikte, wenn vorhanden, sind natürlich dennoch zu beheben. Aber auch das "Zurückfallen" auf eine alte Version und das Erstellen von Patches oder das gezielte Auswählen dedizierter Änderungen aus einem Branch zur Aufnahme in den Hauptentwicklungszweig, das sogenannte "cherry picking", ist immer nur einen Kommandozeilenbefehl entfernt.
Schwere Entscheidung
Um die Arbeit mit einem DVCS beispielhaft im Artikel zu verdeutlichen, hat sich der Autor für Mercurial entschieden, wobei die Wahl zwischen Mercurial und Git schwerfällt. Mercurial ist mittlerweile vielleicht nicht so angesagt wie Git (siehe z.B. diese Meldung auf heise Developer) und hat einen geringeren Nerd-Faktor, aber der Einstieg ist gerade für Umsteiger und Nicht-Nerds mit Mercurial wesentlich einfacher. Allein die schiere Befehlsflut von Git erschlägt einen armen Subversion-Nutzer (es müssten inzwischen um die 180 sein). In Mercurial ist die Anzahl der Basisbefehle überschaubar. Der Benutzer kommt dort mit den komplexeren, in Extensions gekapselten Funktionen nur bei Bedarf in Berührung. Viele Erweiterungen werden bereits mit Mercurial ausgeliefert und stehen sofort zur Verfügung, wie gpg für das Signieren der Changesets oder patchbomb für das Versenden von Changesets als Patch-E-Mails. Andere Extensions wiederum sind herunterzuladen, während ein Git-Benutzer, wie oben erwähnt, den vollen Befehlsumgang sofort zur Verfügung hat.
Alles in allem bieten beide Systeme ähnliche Funktionen und die Konzepte sind weitgehend deckungsgleich (siehe eine Übersicht unter selenic.com), für den Autor ist Mercurial aber transparenter und verständlicher.
Technisch gibt es in den Tiefen der Systeme die einen oder anderen größeren Unterschiede, die aber ein normaler Benutzer in einem Projekt vermutlich überhaupt nicht wahrnehmen wird. Der Einstieg für einen Anwender, der aus der CVS-/Subversion-Welt kommt, geschieht in Mercurial einfach. Insbesondere ist die Mercurial-Dokumentation gut ausgearbeitet, während bei Git der Benutzer vielleicht auch mal zu einer Suchmaschine greifen muss.
Die Infrastruktur der beiden Systeme ist ebenfalls relativ ähnlich, wobei die Sichtbarkeit des Git-Ökosystems durch den derzeitigen Hype (oder besser: den Fanboyismus) größer ist. Da gibt es größere Hoster wie GitHub, die das "soziale Coden" propagieren und unter bestimmten Bedingungen kostenlos Repositories hosten. Auch bietet inzwischen Google Code, viele meinen viel zu spät, neben einer Subversion- und Mercurial-Unterstützung auch die für Git an. Analog wird der Leser mit Bitbucket für Mercurial fündig. Über solche Dienste liegen wieder zentrale Server vor, die als Dreh- und Angelpunkt zur Synchronisation der Änderungen dienen können.
Beide Systeme sind ausgereift und befinden sich teilweise in sehr großen Projekten im Einsatz. Erwähnenswert wären bei Git das Linux-Kernel-Projekt, Gnome oder auch Eclipse, dessen kommende Version, Juno, mit Git versioniert wird. Mercurial steht dem nicht nach und kann ebenfalls auf namhafte Projekte verweisen. Besonders sichtbar sind die Plattformen Google Code und Microsofts CodePlex sowie OpenJDK und NetBeans.
