Quellcodeverwaltung mit Arch

Versionsverwaltung dient dazu, Dateien und ihre Weiterentwicklung zu verfolgen. Die Quellcodedateien eines Programms zum Beispiel ändern sich mit der Zeit: Fehler werden behoben, neue Eigenschaften hinzugefügt, ... In größeren Projekten (also allen, die nicht von einem einzigen Programmierer bearbeitet werden) ist es wichtig, Änderungen an den Dateien zu koordinieren und zwischen den beteiligten Programmierern zu kommunizieren. Außerdem müssen Änderungen, die die verschiedenen Projektmitarbeiter vornehmen, in eine gemeinsame »offizielle« Version des Quellcodes integriert und nachvollziehbar dokumentiert werden. Schließlich sollte es möglich sein, Änderungen (oder Gruppen von Änderungen) auch wieder kontrolliert rückgängig zu machen. Die Dateien, die der Versionsverwaltung unterliegen, werden in einer Versionsdatenbank (Repository) gespeichert, die es möglich macht, jede darin gespeicherte Version irgendeiner Datei zu rekonstruieren.

Quellcodeverwaltung ist Versionsverwaltung für große Programmierprojekte. Ein Quellcodeverwaltungssystem kann zum Beispiel ein Verzeichnis der beteiligten Quellcodedateien aufstellen und aktuell halten und in den Projektverzeichnissen »echte« Quellcodedateien von temporären Hilfsdateien unterscheiden. Ferner kann es Sie benachrichtigen, wenn Quellcodedateien hinzukommen oder entfernt oder umbenannt werden.

In komplexen Projekten wird die Quellcodebasis oft aus mehreren Teilprojekten zusammengesucht. Ein Projekt könnte neben den eigentlichen, projektspezifischen Anteilen auch eine oder mehrere Bibliotheken integrieren, die parallel mit dem Projekt weiterentwickelt werden, aber auch von anderen Projekten benutzt werden. Änderungen und Verbesserungen an diesen Bibliotheken müssen zwischen diesen Projekten kommuniziert werden. Hierbei spricht man von Konfigurationsmanagement.

Eine weitere Aufgabe des Konfigurationsmanagements ist es, neben den eigentlichen Quellcodedateien verschiedene »Konfigurationen« der Software zu verwalten. In eine gegebene ausführbare Version eines Programms gehen neben dem Quellcode ja auch Aspekte ein wie bestimmte Übersetzeroptionen, die für manche Plattformen notwendig sind und für andere nicht. Für jede plattformspezifische Version eines Programms muss reproduzierbar nachvollzogen werden können, wie diese Version erstellt worden ist.

Unix als Programmierer-Betriebssystem verfügte schon früh über Versionsverwaltungssoftware. Das erste weit verbreitete solche System war SCCS, das von AT&T als Bestandteil des »Programmer's Workbench«-Produkts kommerziell vertrieben wurde. Ein frühes frei verfügbares Versionsverwaltungssystem war RCS von Walter Tichy. Sowohl SCCS als auch RCS können nur einzelne Dateien verwalten; sie haben kein Konzept von zusammengehörenden Dateien, die gemeinsam eine Softwareversion ausmachen. Ferner beruhen sie auf dem »Büchereikonzept«: Jede versionsverwaltete Datei kann von genau einem Entwickler für Änderungen »ausgeliehen« (»ausgecheckt«) werden; andere Entwickler können die Datei höchstens lesen, bis der betreffende Entwickler die neue Version wieder »eincheckt«. Es ist möglich, außer der »Hauptentwicklungslinie« einer Datei »Äste« (branches) einzuführen; während die Hauptentwicklungslinie aus den Dateiversionen 1.1, 1.2, 1.3, ... besteht, kann man zum Beispiel ausgehend von der Version 1.2 einen Ast mit separaten Versionen 1.2.1.1, 1.2.1.2, ... zu verwalten. Die Unterschiede zwischen Versionen auf verschiedenen Ästen und der Hauptentwicklungslinie lassen sich später zum Beispiel auf die Hauptentwicklungslinie zurückübertragen. So ist es beispielsweise möglich, einen Fehler in Version 1.2 zu reparieren, während die Hauptentwicklungslinie sich bereits auf 2.0 zu bewegt. Die Fehlerreparatur als Unterschied zwischen (etwa) 1.2 und 1.2.1.2 kann später zum Beispiel in die Version 1.8 übernommen werden.

CVS wurde auf der Basis von RCS von Brian Berliner entwickelt, mit Zuarbeit diverser anderer Freiwilliger. In CVS ist es möglich, Hierarchien von Dateien als Ganzes zu verwalten. Außerdem erlaubt CVS, daß mehrere Entwickler gleichzeitig dieselbe Datei modifizieren. Konflikte werden beim Einchecken erkannt und können manuell behoben werden. CVS erweitert das Konzept der Branches auf ganze Verzeichnishierarchien, so daß ein »Schnappschuß« eines Dateibaums gespeichert und zur Grundlage einer alternativen Entwicklungslinie gemacht werden kann. Im Rahmen der Weiterentwicklung von CVS kamen Eigenschaften dazu wie der Zugriff auf die Versionsdatenbank über das Internet.

CVS macht gewisse Einschränkungen für die Operationen, die auf der Versionsdatenbank möglich sind. Zum Beispiel ist es nicht möglich, Dateien umzubenennen und dabei deren Versionsgeschichte beizubehalten; Verzeichnisse können innerhalb von CVS überhaupt nicht umbenannt werden. Dies sowie die Tatsache, daß die CVS-Quellcodebasis inzwischen als unwartbar gilt, führten zur Entwicklung von Subversion als designiertes Nachfolgesystem von CVS. Subversion verzichtet auf das RCS-Dateiformat als Unterbau und verwendet statt dessen ein binäres, transaktionsorientiertes Datenbankformat auf der Basis von Berkeley DB; für den Netzwerkzugriff auf die Versionsdatenbank wird das WebDAV-Protokoll auf der Grundlage von HTTP verwendet.

Wie CVS beruht auch Subversion auf der Idee einer zentralen Versionsdatenbank. Das bedeutet, daß Operationen wie das Ein- und Auschecken von Dateiversionen oder das Anlegen neuer Branches nur möglich sind, wenn man (direkt oder über das Netz) Zugriff auf die Versionsdatenbank hat. Freie Softwareprojekte gestatten oft beliebigen Personen das Auschecken von Dateiversionen; das Privileg, neue Dateiversionen in die Versionsdatenbank einchecken zu können, bleibt jedoch meist besonders akkreditierten Entwicklern vorbehalten. Dies ist eine wichtige Voraussetzung dafür, die Integrität der Software zu sichern und das Einschmuggeln von bösartigen (»trojanischen«) Dateiversionen zu verhindern. CVS und Subversion sind jedoch nicht immun gegen direkte Manipulationen der Versionsdatenbank nach einem Einbruch in den Server, auf dem diese verwaltet wird.

Arch ist ein unabhängig entwickeltes Quellcodeverwaltungssystem, erfunden von Tom Lord und unter der GPL veröffentlicht. Es besticht vor allem durch seine simple Struktur, seine gut durchdachten Eigenschaften und dadurch, dass es die üblichen Probleme von CVS löst. Arch empfiehlt sich daher als Alternative zu Subversion in der Nachfolge von CVS. Der Rest des Vortrags gibt eine kurze Einführung in die Möglichkeiten von Arch, vergleicht Arch mit CVS und Subversion und gibt einen Ausblick auf Hilfsprogramme für Arch und weitere Informationsquellen im World-Wide Web.

In GNU Arch werden Versionsdatenbanken als »Archive« bezeichnet. Ein Archiv kann verschiedene Projekte enthalten, wobei innerhalb eines Projekts verschiedene »Branches« und innerhalb eines »Branches« mehrere »Versionen« enthalten sein können. Jede Version besteht aus einem ursprünglichen Dateibaum und einer Folge von »Changesets« oder »Revisionen«, von denen jedes eine komplette, zusammengehörende Änderung des Dateibaums beschreibt, zusammen mit einem erklärenden Protokoll. Ein Changeset enthält »Patches« mit den textuellen Änderungen an existierenden Dateien des Projekts sowie Informationen über neu angelegte, gelöschte oder umbenannte Dateien und Verzeichnisse. Changesets sind »atomar«; sie werden entweder im ganzen auf einen Dateibaum angewendet oder gar nicht.

Üblicherweise hat jeder Entwickler in einem Projekt, das mit Arch verwaltet wird, sein eigenes Archiv. Archivnamen bestehen aus einer E-Mail-Adresse und (optional) einem Namen, getrennt durch zwei Minuszeichen:

(Die E-Mail-Adresse muß nicht wirklich existieren, auch wenn das in vielen Fällen eine gute Idee ist.) Hier ist »2004-beispiel« der optionale Name.

Innerhalb von Archiven existiert nochmals eine dreistufige Namenshierarchie, etwa

Dabei ist »beispiel« der Kategoriename, »mainline« der Name des »Branch« und »1« der Name der Version. Changesets heißen »base-0« oder »patch-1«, »patch-2«, ... Der komplette Name einer Revision ist also etwas wie

Arch ist eigentlich weniger ein Programmpaket als ein Format für Archivdateien. Die heute aktuelle Implementierung der Arch-Software heißt »tla« (Tom Lord's Arch); alle Arch-Kommandos haben also die Form

Eine Liste der verfügbaren Unterkommandos erhält man mit »tla help«; Hilfe zu jedem einzelnen Unterkommando ist über »tla UNTERKOMMANDO -H« zu bekommen.

Um Versionsmanagement mit Arch zu betreiben, sind einige einmalige Vorarbeiten nötig. Zuerst ist eine persönliche »Arch ID« zu registrieren, nach Konvention eine E-Mail-Adresse:

Diese ID wird in Archiven und Protokollnachrichten verwendet und kann jederzeit abgefragt werden:

Als nächstes wird ein (leeres) Archiv angelegt:

Ein Verzeichnis (in dem schon Dateien stehen dürfen) wird wie folgt zu einem Arch-Arbeitsverzeichnis erklärt:

Damit wird ein Verzeichnis »{arch}« in dem betreffenden Verzeichnis angelegt, das die Arch-internen Verwaltungsdateien für das Projektverzeichnis enthält.

Anschließend müssen die Dateien im Verzeichnis, die mit Arch verwaltet werden sollen, angemeldet werden:

Mit dem »tla add«-Kommando bekommt die Datei eine eindeutige Kennung zugeordnet, die es möglich macht, diese Datei auch dann zu identifizieren, wenn sie umbenannt oder in ein anderes Unterverzeichnis im Projektverzeichnis verschoben wurde.

Das Kommando »tla tree-lint« gibt unter anderem aus, welche Dateien (noch) keine Kennungen bekommen haben. Damit kann man prüfen, ob man alle relevanten Dateien unter Arch-Kontrolle gestellt hat. »tla inventory« erlaubt eine »Bestandsaufnahme« des Projektverzeichnisses: Arch teilt die Dateien im Projektverzeichnis ein in Quellcode, Backups, »wertvolle« Dateien und »Schrott« (junk) und gestattet die Abfrage nach diesen Kategorien. Die Einteilung ergibt sich auf der Basis des Dateinamens anhand von Kriterien, die der Benutzer modifizieren kann.

Nach dem Registrieren der zu verwaltenden Dateien kann der aktuelle Stand mit dem Kommando »tla import« ins Archiv übernommen werden. Damit wird eine »base-0«-Revision für das Projekt angelegt:

Nach dem Importieren der ersten Fassung kann man wie gewohnt mit dem Projektverzeichnis weiterarbeiten: Code schreiben oder ändern, übersetzen, testen ... Ist ein Punkt erreicht, wo man gerne eine neue Revision im Archiv sichern möchte, sollte man zunächst eine Protokolldatei anlegen, um die Änderungen zu dokumentieren:

(Natürlich kann man auch irgendeinen anderen Editor benutzen.) Nützlich sind hierfür zum Beispiel die Kommandos »tla changes«, das die Namen der gegenüber der letzten eingecheckten Revision geänderten Dateien liefert, oder »tla file-diffs«, mit dem man die genauen Unterschiede zwischen einer Datei und ihrem Pendant im Archiv herausfinden kann. Oft ist es auch eine gute Idee, die Protokolldatei schon am Anfang der Änderungen zu erzeugen und dann während der Arbeit als »Notizzettel« zu verwenden.

Anschließend können die Änderungen ins Archiv übernommen werden:

Arch konstruiert dann ein »Changeset«, das außer allen textuellen Dateiänderungen auch alle Änderungen an Dateinamen (Umbenennungen, Verschiebungen) und Dateimetadaten enthält, die seit dem letzten Einchecken vorgenommen wurden.

Mitarbeiter am selben Projekt können Zugriff auf das Archiv bekommen, indem sie es registrieren:

Anschließend können sie ein eigenes Projektverzeichnis mit der aktuellen (oder irgendeiner) Version eines der Projekte im Archiv anlegen:

In ihren Projektverzeichnissen können die Mitarbeiter dann walten, wie sie mögen. Änderungen können sie mit »tla commit« ins gemeinsame Archiv einfließen lassen.

Arbeitet man zu mehreren am selben Projekt, so muß man sich von Zeit zu Zeit auf den neuesten Stand bringen. Hierzu bietet Arch unter anderem die Kommandos »tla missing« (welche Changesets im Projekt fehlen im Projektverzeichnis?) und »tla update« und »tla replay«, die Changesets aus dem Archiv ins lokale Projektverzeichnis übernehmen. Das Kommando »tla star-merge« ist ein mächtiger Operator zum Übertragen von Changesets aus verschiedenen Projektverzeichnissen in eine gemeinsame »offizielle« Version.

Arch kann auf verschiedene Weise auf Archive zugreifen, außer über direkten Dateizugriff zum Beispiel über FTP, SFTP, HTTP oder WebDAV. Dabei ist über das jeweilige Protokoll hinaus keine spezielle Serversoftware notwendig; für SFTP-Zugriff reicht zum Beispiel ein OpenSSH- oder für HTTP-Zugriff ein gewöhnlicher Web-Server aus. Das macht es einfach, Arch-Archive zum Beispiel auf SourceForge anzubieten, obwohl SourceForge Arch nicht explizit unterstützt (jeder andere Webspace-Anbieter kommt genauso in Frage). Um ein Archiv öffentlich zugänglich zu machen, muß man es nur irgendwo ablegen, wo andere darauf zugreifen können. Die anderen können das betreffende Archiv dann wie üblich registrieren:

Entwickler, die ihr Archiv auf einem Rechner liegen haben, der nicht permanent mit dem Internet verbunden ist, können Archs Fähigkeiten einsetzen, Archive zu spiegeln. Dabei wird zum Beispiel auf einem Web-Server eine Kopie des Archivs angelegt, die dann für andere Benutzer zum Lesen zugänglich ist. Auf Archiv-Spiegeln können keine Commit-Operationen ausgeführt werden

Arch macht es sehr einfach, »Branches« von existierenden Projekten anzulegen, und ermöglicht so das bequeme Entwickeln von unabhängigen Änderungen. Dazu ist keine explizite Zustimmung oder gar Aktion des »Projekteigentümers« erforderlich – die bei herkömmlichen Quellcodeverwaltungssystemen wie CVS oder Subversion nötige Aufteilung der Welt in »Committer«, die Schreibzugriff auf die zentrale Versionsdatenbank haben, und andere Entwickler, die ohne Quellcodeverwaltung existieren müssen, fällt weg. Jeder Interessierte kann die »offizielle« Version des Projekts holen, seine eigenen Änderungen machen und die resultierenden Changesets dann den Projektverantwortlichen in seinem eigenen öffentlichen Archiv anbieten. Diese Vorgehensweise kommt vor allem der Idee der freien Software sehr entgegen. -- Die Methode ist sehr einfach: Wie im vorigen Abschnitt registriert man das gewünschte Archiv und holt sich die aktuelle Revision mit »tla get«. Hat man einen Fehler korrigiert oder eine neue Eigenschaft für das Projekt implementiert, stellt man den entsprechenden »Branch« in sein eigenes öffentliches Archiv und macht den Entwickler des »offiziellen« Projekts darauf aufmerksam. Dieser kann auf das neue Changeset zugreifen, es prüfen und gegebenenfalls in die offizielle Version integrieren. Im Idealfall bietet man für jede Fehlerkorrektur oder jede neue Eigenschaft einen eigenen »Branch« an; alternativ kann man auch möglichst komplette Changesets für die Korrekturen einzelner Fehler in etwas wie

schreiben.

Dieser Überblick stellt nur einen winzigen Teil der Möglichkeiten von Arch dar. Eine detailliertere Einführung findet sich zum Beispiel auf http://regexps.srparish.net/tutorial-tla/arch.html .

CVS ist das traditionelle Quellcodeverwaltungssystem für freie Software und Subversion sein designierter Nachfolger. Subversion erfreut sich zunehmender Beliebtheit, warum sollte man sich also mit Arch beschäftigen?

Der Hauptunterschied zwischen CVS und Subversion auf der einen und Arch auf der anderen Seite ist, daß Arch verteilte Entwicklung zuläßt. Entwickler sind nicht darauf angewiesen, Zugriff auf die zentrale Versionsdatenbank zu haben, sondern können mit ihrem eigenen Archiv arbeiten (etwa im Zug oder im Garten). Es gibt eine Erweiterung von Subversion namens »SVK«, die für verteilte Entwicklung gedacht ist; allerdings ist das in Subversion bzw. SVK eine sehr neue und zusätzliche Idee, in Arch dagegen ein grundlegendes Entwurfsmerkmal. Bis SVK die Stabilität von Arch erreicht, wird es also noch etwas dauern.

Subversion repariert viele der Macken von CVS, zum Beispiel beim Umbenennen von Dateien oder beim Einchecken der Änderungen für ganze Dateibäume (wo es in CVS die Gefahr gibt, daß jemand anderes, der gleichzeitig denselben Dateibaum auscheckt, eine inkonsistente Version dieses Baums bekommt) – bei Subversion wie auch bei Arch sind Commit-Operationen »atomar«, das heißt, sie werden »schlagartig« auf das Archiv angewendet, so daß es nicht möglich ist, einen inkonsistenten Baum abzurufen. Subversion behält jedoch viele der Grundideen von CVS bei, etwa das Konzept eines einzigen sich weiterentwickelnden Dateibaums, von dem »Schnappschüsse« im Archiv landen. Arch dagegen legt größeres Gewicht auf Changesets, die die Unterschiede zwischen zwei Dateibäumen wiedergeben. Changesets können zwischen zwei beliebigen Dateibäumen gebildet werden, die irgendwo in ihrer Vergangenheit einen gemeinsamen Vorfahren haben, und dann auf einen dritten Dateibaum angewendet werden.

Durch seinen Fokus auf Changesets verfügt Arch über ein größeres Spektrum an Operatoren zum »Merging«, zum Zusammenführen von Änderungen aus verschiedenen Dateibäumen. Während bei CVS und Subversion bestimmte Personen das Recht haben, ihre Änderungen direkt in den zentralen Dateibaum einzubauen, erlaubt Arch auch die umgekehrte Vorgehensweise, bei dem der Projektentwickler oder seine Helfer sich interessante Changesets aus den Arch-Archiven der verschiedenen anderen Entwickler holen (cherrypicking). Dies ist der Prozeß, den beispielsweise Linus Torvalds für den Linux-Kern verwendet;er gestattet eine weitaus feinere Kontrolle darüber, welche Änderungen tatsächlich im »offiziellen« Projekt landen. Mit Arch ist natürlich auch eine CVS-artige Entwicklungsmethodik mit designierten »Committern« möglich, etwa mit Zugriff auf die Versionsdatenbank über SFTP oder WebDAV; sie entspricht aber weniger der »Philosophie« des Werkzeugs.

Ein weiterer Unterschied zwischen Arch und Subversion besteht in der Speicherung der Versionsdatenbank. Subversion verwendet hierfür ein transaktionsorientiertes »Dateisystem« auf der Basis von Berkeley DB; Arch beschränkt sich auf herkömmliche Verzeichnisse und Dateien in einem Unix-artigen System. Der Vorteil von Archs Ansatz ist hier, daß grundsätzlich ein direkter Zugriff auf alle vorigen Revisionen des Projekts möglich ist, und zwar mit sämtlichen Unix-Werkzeugen, nicht nur mit den Möglichkeiten, die Subversion zum Zugriff auf die Versionsdatenbank anbietet. Natürlich kostet das einigen Plattenplatz. Subversion erlaubt den Export der Versionsdatenbank in ein textorientiertes Format, so daß nicht zu befürchten ist, daß das binäre Format zum »Datengrab« wird, außerdem ist Berkeley DB ein sehr gut verstandenes und stabiles System. Trotzdem hat Archs weitgehender Rückgriff auf Unix-Konzepte und -Werkzeuge natürlich einen besonderen Reiz.

Schließlich gestattet Arch signierte Archive und CVS und Subversion nicht (diese Eigenschaft wird für SVK angedacht). Gerade im Freie-Software-Umfeld, wo Versionsdatenbanken im Internet zur Verfügung stehen, ist dies eine wichtige Sache: Die Einbrüche in die Debian- und GNU-Server sowie den CVS-Server für den Linux-Kern unterstreichen, daß die Integrität der Codebasis von Projekten wie Linux ein immer interessanteres Angriffsziel zu sein scheint. Arch erlaubt es, die Integrität von Changesets und Archiven über digitale Signaturen zu sichern, so daß die Manipulation eines Archivs oder das Einschmuggeln eines unautorisierten Changesets erkannt werden kann.

BitKeeper ist das Quellcodeverwaltungssystem, das Larry McVoys Firma BitMover speziell für die Bedürfnisse von Linus Torvalds entwickelt hat. Die Architektur von BitKeeper ist nicht unähnlich der von Arch; auch BitKeeper stellt Changesets gegenüber Dateibäumen in den Vordergrund und erlaubt die verteilte Softwareentwicklung mit entwicklerspezifischen Archiven. BitKeeper ist kein freies Programm, sondern proprietär und mit einer sehr eigenartigen Lizenz für die kostenlose Benutzung versehen; der Einsatz von BitKeeper für den Linux-Kern hat darum einigen Ärger in der Szene verursacht und ist immer noch nicht unumstritten. Ein Ziel des Arch-Projekts ist es, eine freie Alternative zu BitKeeper für die Zwecke der Linux-Kern-Entwicklung anzubieten; ob man Linus Torvalds dazu bringen kann, von BitKeeper auf Arch umzusteigen, ist allerdings eine offene Frage.

Zu den technischen Unterschieden zwischen Arch und BitKeeper lassen sich wenige definitive Aussagen machen, da die Gratis-Lizenz explizit solchen Leuten nicht zur Verfügung steht, die an anderen Quellcodeverwaltungssystemen arbeiten. Die einhellige Meinung scheint zu sein, daß BitKeeper zur Zeit das leistungsfähigste Quellcodeverwaltungssystem am Markt ist, daß Arch aber durchaus nicht weit hinter BitKeeper zurücksteht, jedenfalls was diejenigen Merkmale angeht, die man tatsächlich braucht. BitKeepers Stärke sind derzeit leistungsfähige GUI-Programme zum Beispiel zum »Mergen« verschiedener Programmversionen.