Fossil vereint Versionskontrolle, Wiki und Bugtracker zum Rundum-Wohlfühl-Paket für Software-Entwickler.

Tragen Teams aus Entwicklern und Anwendern Daten für den Programmcode und die Dokumentation einer Applikation gemeinsam zusammen und pflegen diese, dann sind Kollisionen im Rahmen dieser Kooperation vollkommen normal. Dabei passieren auch Fehler – etwa dass Inhalte auf mysteriöse Weise verloren gehen oder sich verändern. Daher kommt oft nachträglich der Wunsch auf, die Dateien zu revidieren und frühere Versionen wieder zu reaktivieren – mit anderen Worten: Archäologie vom Feinsten.

Das Verschicken einer Version als Anhang an eine Mail (und infolgedessen ein verstopftes Postfach) zählt zum Leidwesen vieler immer noch zum Alltag. So etwas lässt sich mit dem Einsatz eines geeigneten Versionkontrollsystems (VCS) verhindern, englisch “revision control system” (RCS) genannt. Darin verwalten Sie die gemeinsam bearbeiteten Dateien.

Ein solches System dient zum Erfassen von Änderungen an Dokumenten oder Dateien. Alle Versionen erhalten einen Zeitstempel und in der Regel eine Benutzerkennung. Neuere Varianten versehen die Daten zusätzlich mit einem Hash-Wert (siehe Kasten “Unterschiede”). Als Archiv kommt eine einzelne Datei, ein Verzeichnis oder eine Datenbank zum Einsatz. Daraus holen Sie bei Bedarf jede Version und Zustand des Archivs wieder zurück.

Der Sinn eines VCS besteht darin, nachzuvollziehen, wer wann welchen Inhalt geändert hat. Dazu gehört die Möglichkeit, diese Änderungen wieder vollständig rückgängig zu machen. Bei Office-Dokumenten heißt diese Funktion häufig “Änderungshistorie im Dokument”. Ähnliches verwenden Wikipedia und viele Content-Management-Systeme.

So ermöglicht ein VCS eine nachvollziehbare Zusammenarbeit, insbesondere von unterschiedlichen Orten aus. Jeder Benutzer trägt etwas bei, sofern er Zugang zum verwendeten System besitzt. Das VCS repräsentiert den Entwicklungsstand und somit eine Version mit bestimmten Eigenschaften, wie bereits getestete und freigegebene Funktionen einer Software.

Es erlaubt das Freigeben einer bestimmten Version, während andere parallel daran weiterarbeiten. Verschiedene Zweige – benannt als Entwicklung oder Veröffentlichung mit Versionsnummer – erlauben ein Ausprobieren und späteres Zusammenführen von Programmcode der einzelnen Beitragenden.

Die Auswahl eines VCS hängt von der Anzahl der Beteiligten und von den Bedürfnissen im Projekt selbst ab. Klären Sie vorher, was Sie alles abdecken und welche weitere Software Sie daran andocken möchten. Das betrifft insbesondere die grundlegenden Komponenten wie Betriebssysteme. Zudem freuen sich Entwickler sehr, wenn Sie deren Gewohnheiten in der Arbeitsweise berücksichtigen. Das spätere Migrieren zu einem anderen System gestaltet sich mitunter recht aufwendig und nie konfliktfrei.

Dieser Beitrag rückt Fossil [1] ins Rampenlicht. Es verbindet ein VCS mit einem integrierten Wiki und einem Bugtracking-System. Von daher bricht es mit dem KISS-Prinzip [2], das die meisten Werkzeuge unter Linux bei der Konzeption als Maßstab anlegen. Können Sie mit dieser Einschränkung leben, erhalten Sie ein dezentral angelegtes, überschaubares und mächtiges Werkzeug, das ideal zu Projekten kleiner und mittlerer Größe passt.

Einstieg in Fossil

Fossil gehört zur Klasse der dezentral organisierten VCS. Sie können auch eine Instanz nutzen, die als Server fungiert, müssen das aber nicht tun. Um die einzelnen “Commits” (Änderungen) beim Zusammenführen (Synchronisieren) den verschiedenen Instanzen zuzuordnen, referenziert Fossil jede Änderung über einen Hash (siehe Kasten “Hash-Wert berechnen”).

Wie jedes VCS kommt Fossil am besten mit zeilenorientiert abgelegten ASCII-Daten zurecht – etwa Programmcode, HTML und CSS, Texte, Konfigurationsdateien und Notizen. Änderungen ordnen Sie über eine Zeilennummer zu. Bei anderen Daten – übersetzter Programmcode, Bilder und komprimierte Dateien wie Zip-Archive – helfen spezielle Erweiterungen wie Git-annex [3] weiter [4].

Fossil richtet sich an einzelne Entwickler und Teams bis mittlerer Größe. Im Fokus stehen insbesondere Gruppen, die zur Pflege der einzelnen Werkzeuge über keine große Manpower verfügen. Hierin liegt auch der Grund dafür, dass Fossil neben dem VCS noch ein Wiki, ein Bugtracking-System sowie eine Funktion zum Hinterlegen von Notizen (“Technical Notes”) mitbringt. Letztere verbinden Sie mit einem Zeitpunkt und verwenden das als Ankündigung, Blog-Eintrag oder Meilenstein. Fossil verlinkt die Notiz automatisch über das Wiki.

Dabei vereint eine einzige Programmdatei alle genannten Funktionen miteinander. In der Programmiersprache C geschrieben, fällt sie sehr kompakt aus und bringt nicht mehr als 2 MByte kompilierten Code auf die Waage. Als DEB-Paket findet sich Fossil in den Repositories von Debian, Ubuntu und deren Ablegern. Alternativ beziehen Sie ein spezifisches ZIP-Archiv von der Webseite des Projekts, um Fossil unter Linux, MacOS, OpenBSD oder Windows einzuspielen.

Zum Speichern der versionierten Daten stützt Fossil sich auf die Datenbank SQLite [7], zu der es auch komfortable grafische Verwaltungsoberflächen gibt [8]. Auf Wunsch im- und exportiert das Tool die verwalteten Daten samt Historie von und zu Git.

Nach der Installation benutzen Sie Fossil über die Kommandozeile. Haben Sie bereits mit einem anderen VCS wie Git gearbeitet, finden Sie sich schnell zurecht. Der Aufruf folgt dem Schema aus Listing 1. Praktische Beispiele zeigt die Tabelle “Fossil vs. Git”. Alternativ zur Kommandozeile steht eine integrierte Schnittstelle via Web bereit, daneben existieren grafische Benutzeroberflächen für Fossil.

Dazu gehören etwa Fuel [9], Fossil-GUI [10] für Mac OS X, Jurassic-Fossil [11] und QL-Fossil [12]. Die beiden Letzteren nutzen Java beziehungsweise C und haben bereits etwas Staub angesetzt. Keines der Programme steht derzeit für Debian oder Ubuntu als Paket bereit, es finden sich lediglich vereinzelt ältere Varianten für Arch Linux.

$ fossil Kommando|Schalter Aktion Repository

In der Praxis

Als ersten Schritt bei der Arbeit richten Sie ein neues Repository ein (Listing 2, erste Zeile). Dabei legt das Programm eine Projektdatei mit dem Namen des Repositorys im aktuellen Verzeichnis an, als Format verwendet es eine SQLite-Datenbank. Fossil vergibt hierbei eine Projekt- und eine Repository-ID, außerdem generiert es für das Repo den administrativen Benutzer admin mit einem zufälligen Passwort (Abbildung 1).

Abbildung 1: Mit einem einzigen Befehl legen Sie ein neues Repository an.

$ fossil init Repository
$ fossil user list -R Repository
$ fossil user password User Passwort -R Repository
$ fossil server -P Port Repository

Von Anfang an erhalten neben admin auch die Benutzer anonymous, developer, nobody und reader Zugriff auf das Repository. Sofern Sie nicht das Admin-Menü in der webbasierten Bedienoberfläche benutzen, erhalten Sie die Liste der Benutzer über den Befehl aus der zweiten Zeile von Listing 2.

Es gibt keine Möglichkeit, bestehende Benutzer aus dem Repository zu löschen – Sie dürfen nur deren Zugang einschränken. Fossil interpretiert einen Benutzer als gesperrt, sobald er ein leeres Passwort besitzt. Um das Passwort zu ändern, verwenden Sie das Kommando aus Listing 2, Zeile 3. Beachten Sie, dass hier die Kombination aus Benutzername und Passwort im Klartext in der Historie der Kommandozeile verbleibt. Das VCS selbst speichert dagegen nur den SHA1-Hash des Passworts in der Datenbank im Repository.

Haben Sie ein neues Repository angelegt, bedarf dieses noch des Feintunings. Über einen Webbrowser greifen Sie darauf zu und nehmen weitere Einstellungen vor. Dazu starten Sie Fossil zunächst als Webserver (Listing 2, Zeile 4). Geben Sie im Aufruf den Schalter -P (Langform --port) nicht an, nutzt Fossil automatisch den TCP-Port 8080 und lässt sich über HTTP erreichen. Die lokale Webseite rufen Sie demnach über die URL http://localhost:8080 auf. Bei Bedarf nutzen Sie aber die Kombination HTTPS/SSL zur sicheren Kommunikation.

Im Browser erfolgt das weitere Setup des Projekts, nachdem Sie sich als Benutzer mit den oben vergebenen Zugangsdaten angemeldet haben. Von den dort vorhandenen Feldern sind für das Projekt drei Dinge essenziell: die Vergabe eines Namens für das Projekt, die Beschreibung sowie ein Home-Verzeichnis. Darüber setzt Fossil einen Pfad zusammen, mit dessen Hilfe Sie später auf das Wiki, den Bugtracker und die Tickets zugreifen.

Über die Leiste zur Navigation, die Sie bei Bedarf individuell zusammenstellen, verwalten Sie Benutzer und Rechte oder greifen auf die erfolgten Commits, die einzelnen Dateien im Repository sowie die Verzweigungen (“Branches”) zu. Abbildung 2 stellt die Sichtbarkeit eines Commits samt dessen Metadaten dar. Diese Anzeige fällt umso ausführlicher aus, je mehr Änderungen im Projekt erfolgt sind.

Abbildung 2: Über das Webinterface schauen Sie im Browser die Informationen zu einem Commit an.

Grundlegend folgt die Arbeit mit dem Programm folgendem Ablauf: Zunächst öffnen Sie ein Repository (fossil open), danach beziehen Sie die möglichen Änderungen (fossil pull) und synchronisieren diese mit dem lokalen Tree (fossil update). Anschließend nehmen Sie Änderungen vor (fossil add, fossil rm, fossil mv, fossil commit), synchronisieren diese (fossil sync) und schließen am Ende das Repository wieder (fossil close).

Timeline

Die Zeitleiste zeigt den Verlauf eines Projekts. Alle Änderungen stellt Fossil in Form eines Graphen dar, der die Zwischenstufen und Verzweigungen umfasst. Neueste Änderungen erscheinen in Form eines Knotens ganz oben; Abbildung 3 zeigt als Beispiel die Entwicklung im (recht aktiven) Fossil-Projekt.

Abbildung 3: Die intensive Arbeit am Projekt schlägt sich in zahlreichen Einträgen im Versionskontrollsystem nieder.

Unter dem Menüpunkt Code oder Files erhalten Sie eine Liste der Inhalte des Projekts. Das Programm zeigt die Dateien und Verzeichnisse in drei Varianten an – alphabetisch sortiert gemäß der Verzeichnisstruktur (All), als Baumstruktur (Tree View) und sortiert nach der letzten Änderung (File Ages). In Abbildung 4 sehen Sie die Baumstruktur des Projekts.

Abbildung 4: Bei Bedarf zeigt das VCS die Inhalte des Projekts als Baumstruktur.

Der Eintrag Docs dient üblicherweise dem Zusammenstellen zusätzlicher Dokumente zum Projekt. Sie hinterlegen dort etwa Handbücher, Anleitungen sowie ein Stichwortverzeichnis. Mit Letzterem erreichen Sie die entsprechend referenzierten Einträge im Wiki.

Programmcode und Projekte entwickeln sich selten vollständig linear. Einzelne Zweige heißen umgangssprachlich Branches und besitzen meist einen spezifischen Namen. Sofern Sie dieses Feature in Fossil verwenden, erhalten Sie unter dem gleichnamigen Menüpunkt eine entsprechende Übersicht und die Möglichkeit, zu den Inhalten eines spezifischen Branches zu recherchieren.

Tickets dienen dazu, Aufgaben zu benennen und einer oder mehreren Personen zuzuordnen. In der Softwareentwicklung kommt diese Vorgehensweise häufig beim Beheben von Fehlern zum Einsatz sowie beim Erweitern von Funktionen (“Feature Request”).

Jeder Fossil-Benutzer darf ein solches Ticket über den Browser erstellen, bearbeiten, einer Kategorie zuordnen, darin suchen sowie es später über die Kombination aus Kommandozeile und Ticket-ID einsehen. Für Letzteres kennt das Programm mit ticket einen speziellen Schalter.

Abbildung 5 zeigt ein ausgewähltes, älteres Ticket aus dem Fossil-Projekt. Das Programm hinterlegt jeweils die Nummer des Tickets sowie dessen Status, also ob es jemand bearbeitet oder ob es noch offensteht. Darüber hinaus setzen Sie darin die Wichtigkeit und geben eine Beschreibung ein. Letztere gibt Auskunft darüber, worum es geht und was zu tun ist. Jedem Status eines Tickets ist eine Farbe zugeordnet, womit Sie den Stand der Bearbeitung auf einen Blick erfassen (Abbildung 6).

Abbildung 5: Ein Ticket gibt auf einen Blick die wichtigsten Informationen preis, die Sie einer Aufgabe zugeordnet haben.

Abbildung 6: Über einen Farbcode haben Sie einen Überblick darüber, wie viele Tickets sich jeweils in einer Kategorie befinden.

Im Wiki laufen alle Informationen eines Projekts zusammen – wie eine dynamische Webseite, zu der jeder Benutzer etwas beiträgt. Sie sehen Änderungen samt Datum und Verfasser. Als Format beim Erstellen der Inhalte greift Fossil auf Markdown [13] zurück [14], sofern Sie das im Admin-Menü nicht in HTML geändert haben.

Fazit

Erfreulicherweise ist Fossil vollständig und verständlich dokumentiert. Es lohnt sich, einen Blick in das Buch von Jim Schimpf [15] zu werfen, das als PDF frei über die Seite des Projekts bereitsteht. Die letzte Veröffentlichung liegt allerdings eine Weile zurück – Fossil hat jedoch zwischenzeitlich etliche Ergänzungen erhalten, die das Buch noch nicht berücksichtigt. In der Summe erweist sich Fossil als schnelles und einfach zu bedienendes Werkzeug. Es wirkt unspektakulär und kommt ohne größere Stolperfallen daher, erfüllt aber seinen Zweck. So macht produktives Arbeiten Spaß.