Open Source im professionellen Einsatz
Linux-Magazin 06/2007
© df.schoenen, photocase.com

© df.schoenen, photocase.com

Verteilte Versionsverwaltung mit Bazaar

Markt-Modell

,

Bei Versionskontrollsystemen wie CVS und Subversion speichert ein zentraler Server alle Dateien. Fällt er aus, ist mit der Arbeit Schluss. Bazaar löst dieses Problem, indem es das Quellcode-Management über die Rechner der Entwickler verteilt.

993

Eine Software zur Versionsverwaltung speichert nicht nur den Quellcode selbst, sondern führt auch akribisch Buch über jede einzelne Änderung. Legt ein Programmierer eine neue so genannte Revision an, erstellt die Versionsverwaltung bei diesem Commit genannten Vorgang einen Schnappschuss seiner Arbeitskopie. Damit ist es dem Entwickler möglich, jederzeit zu einer beliebigen Revision zurückzukehren oder sich die Änderungen und die Versionsgeschichte anzuschauen.

Netzwerk- und mehrbenutzerfähige Versionsverwaltungen erlauben die Zusammenarbeit mehrerer Entwickler an unterschiedlichen Orten. Systeme wie Subversion und CVS stellen dazu ein zentrales Repository bereit. Jeder Entwickler erstellt sich eine Arbeitskopie (Checkout) und legt für jede Änderung an seiner Arbeitskopie eine neue Revision an (Commit oder Checkin), die Subversion beziehungsweise CVS von der Arbeitskopie in das zentrale Repository überträgt.

Arbeiten mehrere Entwickler parallel an der gleichen Datei, kommt es mitunter zu Konflikten. Hat der eine Entwickler bereits seine Änderungen in das Repository übertragen, meldet die Versionsverwaltung dem anderen beim Anlegen einer weiteren Revision einen Konflikt. Seine Änderungen vertragen sich nicht mit den Änderungen des Entwicklers, der schneller war.

Zentral versus verteilt

Revisionen landen bei einer zentralen Versionsverwaltung immer im zentralen Repository. Das erschwert komplexe Änderungen, die mitunter kurz- bis mittelfristig erst einmal eine gewisse Instabilität mit sich bringen. Denn solange ein Entwickler nur mit seiner Arbeitskopie arbeitet, registriert die Versionsverwaltung keine Änderungen. Am Ende bleibt ein großer Haufen an Änderungen, für die der Entwickler nur eine einzige Revision anlegt. Oder er möchte seine Änderungen sichern und legt daher mitunter eine Revision mit Änderungen am Quelltext eines Programms an, die sich nicht einmal kompilieren lassen.

Ein Weg, diesen Nachteil zu umgehen, besteht darin, einen Entwicklungszweig (Branch), also eine Kopie des aktuellen Entwicklungsstands, anzulegen, und diesen nach den Änderungen wieder mit dem Hauptzweig zusammenzuführen (Merge). Weder CVS noch Subversion greifen dem Entwickler dabei unter die Arme. Ein Merge ist daher ein zeitaufwändiger manueller Prozess. Die Informationen über die einzelnen Revisionen des Branch gehen verloren, wenn der Entwickler sie nicht einzeln mit dem Hauptzweig vereinigt.

Ein weiterer Nachteil dieses zentralisierten Vorgehens lässt sich auch mit Branching nicht umgehen: Das Anlegen von Revisionen funktioniert nur dann, wenn eine Verbindung zwischen Client und Server besteht. Ist der Entwickler mit dem Laptop unterwegs und ohne Internetzugang oder ist schlimmer noch der Server ausgefallen, hat er keine Möglichkeit, um Änderungen als Revisionen aufzuzeichnen.

Dagegen arbeitet bei einer verteilten Versionsverwaltung wie Bazaar, Git [1], Monotone, Arch [2] oder SVK [3], das auf Subversion aufsetzt, jeder Entwickler von vornherein mit einem eigenen Entwicklungszweig. Revisionen landen zunächst immer im Branch des Entwicklers, der ein Repository zum Aufzeichnen von Revisionen enthält. Jeder Commit ist daher konfliktfrei.

Erst wenn der Entwickler mit seinen Änderungen zufrieden ist, führt er sie mit Änderungen anderer Entwickler zusammen (Merge). Erst dann zeigen sich eventuell Konflikte, die er manuell auflösen muss. Er hat zudem jederzeit die Freiheit, Änderungen anderer Entwickler in seinen Branch zu übernehmen, ohne seine eigenen Änderungen gleichzeitig zu publizieren.

Die dezentrale Versionsverwaltung Bazaar ist in Python implementiert. Sie entstand, als die Ubuntu-Firma Canonical ein solches System benötigte und auf GNU Arch zurückgriff und es unter dem Namen Bazaar, kurz »baz«, an die eigenen Bedürfnisse anpasste. Der Nachfolger Bazaar-NG, trat später an, um einige noch bestehende Beschränkungen von GNU Arch zu überwinden. Neuere Distributionen verwenden aber nur noch den Namen Bazaar.

Arbeiten mit Bazaar

Ein konkretes Beispiel soll den Entwicklungsprozess genauer beschreiben: Zwei Autoren möchten zusammen an einem Linux-Magazin-Artikel arbeiten. Der eine legt ein Verzeichnis an und verwandelt es mit »bzr init« in einen Branch mit einem Repository in ».bzr/repository«. Er kopiert die Vorlage für den Artikeltext in das Verzeichnis, fügt die Datei mit »bzr add« der Versionsverwaltung hinzu und legt mit »bzr commit -m "Vorlage für Artikeltext"« eine initiale Revision an.

Für die Zusammenarbeit mit dem anderen Autor publiziert er seinen Branch beispielsweise mit »bzr push sftp:// Benutzer1@Server1/var/www/ Projekt« auf seinem Server. Bazaar legt dazu in dem angegebenem Verzeichnis einen neuen Branch mit allen Revisionen des Autors an. Eine Arbeitskopie der Dateien erstellt Bazaar aus Performance-Gründen nicht.

Der andere Autor setzt, sofern dies zuvor noch nicht geschehen ist, mit »bzr whoami "Mein Name <Benutzer2@E-Mail-Adresse.de>"« seine Identität und legt sich mit »bzr branch http:// Server2/Projekt« (oder »bzr get«) einen eigenen Branch an, der alle Revisionen seines Kollegen enthält. Er schreibt am Artikeltext und legt mit »bzr commit« für seine Änderungen neue Revisionen an, die Bazaar zunächst nur im lokalen Branch speichert. Mit »bzr push sftp:// Benutzer2@Server2/var/www/ projekt« legt er wieder eine Kopie seines Branch auf seinem eigenen Server ab.

Nun übernimmt jeder Autor bei Bedarf mit »bzr pull« die Änderungen im Branch des anderen. Legen beide Autoren jedoch unabhängig voneinander neue Revisionen an, entstehen so genannte divergierte Branches. In diesem durchaus üblichen Fall reicht ein »bzr pull« nicht mehr aus, um die Änderungen des Partners zu übernehmen, weil dabei Konflikte auftreten können. Stattdessen führt »bzr merge http:// Server/Projekt« divergierte Zweige zusammen.

Dabei übernimmt Bazaar die komplette Revisionsgeschichte des zusammenzuführenden Entwicklungszweigs (siehe Abbildung 1). Die Revisionsnummern dienen der leichteren Orientierung. Intern verwendet Bazaar Revisions-IDs, die aus E-Mail-Adresse, Datum, Zeit und einer zufälligen Nummer bestehen. Der Befehl »bzr log --show-ids« zeigt die Revisionsgeschichte samt dieser eindeutigen Kennungen.

Glossar

Arbeitskopie: Eine Kopie der Revision, mit der der Benutzer arbeitet, einschließlich der lokalen Änderungen des Benutzers.

Branch: Ein Entwicklungszweig, eine Entwicklungslinie, eine geordnete Folge von Revisionen.

Checkin: Siehe Commit.

Checkout: Eine Arbeitskopie mit etwas Meta-Information über den zugehörigen (gebunden) Branch. Man unterscheidet zwischen leichtgewichtigen (ohne eigene Historie) und schwergewichtigen (mit kompletter Historie) Checkouts.

Commit: Anweisung an die Versionsverwaltung, für den aktuellen Stand der Arbeitskopie eine Revision, einen Fixpunkt (Checkpoint) anzulegen.

Repository: Ein Archiv mit mehreren Revisionen eines Verzeichnisbaums samt Dateien.

Revision: Ein Schnappschuss einer Arbeitskopie, erstellt während eines Commit.

Abbildung 1: Beim Zusammenführen von Branches bleiben alle Revisionen erhalten.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Versionsverwaltung

    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.

  • Bazaar 1.1 bringt Verbesserungen und Bugfixes

    Die Entwickler von Bazaar, einem verteilten System zur Versionskontrolle, reichen rund einen Monat nach Version 1.0 Bugfixes nach. Zudem verbessert Bazaar 1.1 einige Details.

  • Nachfolgemodell

    Obwohl CVS als Versionskontrollsystem nicht das Gelbe vom Ei ist, hat es einen großen Vorteil gegenüber besseren, aber kommerziellen Alternativen: Es ist freie Software. Mit Subversion bekommt es Konkurrenz.

  • Bazaar stellt auf neues Repository-Format um

    Das maßgeblich von der Ubuntu-Firma Canonical entwickelte Versionskontrollsystem Bazaar ist in Version 2.0.0 erhältlich. Diese führt ein neues Format für Repositories ein.

  • Bazaar 1.13 mit nützlichen Details

    Bazaar, das unter anderem dem Ubuntu-Projekt zur Versionskontrolle dient, ist in Version 1.13 verfügbar. Die Release bringt kleine, aber praktische Änderungen.

comments powered by Disqus

Ausgabe 10/2016

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.