Über den Status quo verteilter Versionsverwaltungssysteme

Verteilte Versionsverwaltungssysteme (DVCS, Distributed Version Control System) kommen zunehmend in Mode. Begnügten sich früher Entwickler noch mit einem zentralen CVS-Server, müssen es heute schon Git, Mercurial oder ein anderes verteiltes Versionsverwaltungssystem sein.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 25 Min.
Von
  • Halil-Cem Gürsoy
Inhaltsverzeichnis

Verteilte Versionsverwaltungssysteme (DVCS, Distributed Version Control System) kommen zunehmend in Mode. Begnügten sich früher Entwickler noch mit einem zentralen CVS-Server, müssen es heute schon Git, Mercurial oder ein anderes verteiltes Versionsverwaltungssystem sein.

Der Autor kam das erste Mal mit einem Versionsverwaltungssystem in Form von PVCS in Berührung. Das war ein heute von Serena entwickeltes System, dass früher unter einem "miteinander entwickeln" eher ein "wer zuerst kommt, mahlt zuerst" verstand. Jeder Nutzer musste eine Datei erst exklusiv sperren, bevor er sie verändern durfte. Der weitere Weg ging über MKS (ähnliches Sperrverfahren) und Perforce zu CVS. Die letzten beiden Produkte waren damals eine Offenbarung: Nicht nur, dass sich mit ihnen "konkurrierend" arbeiten ließ, erstmals gab es auch Branches, also Entwicklungszweige. Das Mergen, das heißt das Zusammenführen solcher Entwicklungszweige stellte allerdings eine große Herausforderung dar, wenn mehrfach aus einem Branch in den Hauptentwicklungszweig zu "mergen" war.

Zudem führten die nicht atomaren Commits von CVS zu mancher Überstunde. Denn verabschiedete sich der CVS-Prozess auf dem Server mitten im Commit, war mehr oder weniger mühselig herauszufinden, welche Änderungen der Server aufgenommen hatte und welche nicht.

Mit Subversion bekamen Entwickler und Projektteams endlich ein Handwerkzeug, mit dem sich hinsichtlich der (endlich atomaren) Commits tatsächlich sicher arbeiten ließ. Von Version zu Version wurde die Unterstützung für Merges zwar etwas besser, sie stellt aber immer noch eine große Herausforderung dar: Welche Revisionen wurden bereits zusammengeführt? Was ist mit der Historie aus den Branches? Die gehen gerne verloren, zumal nach einem "Reintegrate" ein Branch stillgelegt wird.

Aber das Mergen ist nicht der einzige Stolperstein, mit dem ein Entwickler in Subversion zu kämpfen hat. Zu nennen wären etwa die Externals, das sind Verweise auf andere Bereiche im gleichen oder in einem anderen Repository: ein Tag, also eine Marke, die einen bestimmten Zustand markiert, auch über Externals zu erfassen ist einfach nicht möglich. Dadurch wird es schwierig, einen bestimmten Zustand zum Beispiel nach einem Release nachvollziehbar zu kennzeichnen.

Die Liste ließe sich fast beliebig fortführen. Diesen Systemen ist gemeinsam, dass sie einen zentralen Server aufweisen. Alle Informationen sind dort abgelegt, die Benutzer haben nur eine Arbeitskopie ohne weitergehende Informationen zu der Historie der versionierten Artefakte. Hat ein Benutzer eine Änderung vorgenommen, muss er sie auf den zentralen Server übermitteln, und die anderen Benutzer müssen eine Aktualisierung durchführen.

Seit dem Wechsel des Linux-Kernel-Projekts um Linus Torvalds auf das eigen entwickelte Git steigt die Sichtbarkeit verteilter Versionsverwaltungssysteme und natürlich von Git selbst. Die Entscheidung, ein eigenes Versionsverwaltungssystem für das Kernel-Projekt zu entwickeln, fiel 2005, als die Lizenz für das bis dahin im Kernel-Projekt eingesetzte kommerzielle System BitKeeper geändert wurde. Anscheinend unterschieden sich die Anforderungen von Torvalds und dessen Umfeld so sehr von der Arbeitsweise von Subversion, dass Torvalds in der Mailingliste zum Linux-Kernel jegliche Diskussion um die Einführung von Subversion mit dem lapidaren Satz "Don't bother telling me about subversion" zu unterbinden versuchte. Erfolgreich, wie die Geschichte gezeigt hat.

Sein Hauptaugenmerk galt dem verteilten, unabhängigen Arbeiten und der Effizienz. Eine klare Gliederung nach "Changesets" sollte her. Das heißt, Torvalds wünschte sich ein System, das ihm als Kernel-Maintainer das Leben vereinfachen sollte: Aus der großen Anzahl an Änderungen, die in den Kernel-Quelltexten stattfinden, kann und will er nur ausgewählte in ein kommendes Kernel-Release aufnehmen. Eine Aufgabenstellung, die zugegeben in einem "normalen Projekt" nicht immer aufkommt.

Getrieben durch eben diese Lizenzänderung wurden weitere Entwicklungen angestoßen: Etwa zur gleichen Zeit entstand das System Mercurial, das Matt Macall ebenfalls in der Kernel-Mailingliste ankündigte und unter der GPL steht. Die Entwicklung von Mercurial schritt schnell voran und in der besagten Mailing-Liste konnte Torvalds es sich nicht verkneifen, darauf auf seine bissig süffisante Art zu reagieren, insbesondere dann, wenn sich Macall erdreistete, Vergleiche zu Git zu ziehen.

Daneben fand die Entwicklung von Bazaar (siehe Kasten) statt, das auf die gleichen Konzepte wie Git und Mercurial setzt. Der Artikel konzentriert sich im Wesentlichen auf Mercurial und Git. Bazaar spielt eine eher untergeordnete Rolle und kommt in der "freien Wildbahn" selten vor.

Mehr Infos

Bazaar

Das unter der GPLv2 stehende Bazaar entstand aus der gleichen Motivation heraus wie Mercurial und Git. Größter Förderer ist Canonical Ltd., Hauptsponsor der bekannten Linux-Distribution Ubuntu. Aus dem Kontext heraus bezieht Bazaar seine größte Verbreitung, da die Entwicklung von Ubuntu sich auf Bazaar stützt. Auch Launchpad, die Plattform um Entwicklungen rund um Ubuntu, setzt Bazaar ein. Aber das System ist nicht nur auf Linux und Ubuntu beschränkt, es finden sich Installationspakete für andere gängige Betriebssysteme, neben Linux-Derivaten und Windows auch für Solaris, BSD und andere.

Die Konzepte von Bazaar unterscheiden sich nicht wesentlich von Mercurial oder Git, auch die Befehle sind sich recht ähnlich. Eine Integration in eine bestehende Subversion-Landschaft ist ohne größeren Aufwand möglich. Ein Eclipse-Plug-in existiert ebenfalls und lässt sich über die Update-Site installieren.