Prof. Dr. Detlef Kreuz

Fossil

Wer etwas ernsthafter programmiert, der weiß eine Art von Software besonders zu schätzen: Versionsverwaltung, auch Versionskontrollsystem genannt. Mit solch einer Software wird verhindert, dass Programmcode aus Versehen überschrieben oder gelöscht wird. Dazu speichert ein solches System, wer wann welche Änderung vorgenommen hat. Als Nebeneffekt bietet eine Versionsverwaltung die Möglichkeit von Zeitreisen an, leider nur in die Vergangenheit. Die gesamte Vergangenheit eines Programmcodes kann damit nachvollzogen und wiederhergestellt werden.

Eine Versionsverwaltung ist nicht nur für das Programmieren unabdingbar, es kann bei allen Arten von Texten helfen. In meiner Umgebung sind es zum Beispiel wissenschaftliche Texte, Seminar- und Abschlussarbeiten. Es kann Corporate Blogging revisionssicher machen, es hilft beim Schreiben von Büchern oder Briefen. Selbst bei einer gemeinsam gepflegten Kochrezeptsammlung können Versionsverwaltungen nützlich sein. Natürlich sind auch die Texte dieses Blogs versioniert. Eat your own dog food.

Die Wahl einer geeigneten Versionsverwaltung ist nicht einfach. Sehr viele IT-Unternehmen verwenden Git, das ursprünglich für die Verwaltung des Betriebssystems Linux entwickelt wurde. Ich selbst verwende in meinen studentischen Projektstudien Mercurial, das eine ähnlich gute Unterstützung erfährt und, nach meinen Erfahrungen, besser unter Windows läuft. Andere setzen auf Subversion, um die Vorteile eines zentralen Systems zu nutzen. Man kann Software zur Versionsverwaltung auch (mit-) kaufen. Bekanntes Beispiel sind die entsprechenden Produkte von Microsoft (als Teil des Team Foundation Server). Alle Systeme besitzen Vor- und Nachteile.

Git ist so etwas wie das Microsoft unter den Versionsverwaltungen: es wurden eher wenige entlassen, weil sie Git verwendeten. Ich halte Git für ein extrem leistungsfähiges Werkzeug, dass in die Hände erfahrener Menschen gehört. So wie bei einem Rasiermesser kann man damit viel erreichen, sich aber auch einfach die Kehle durchschneiden. Git ist (auch) deshalb so populär, weil es mit GitHub einen Dienst gibt, der als soziale Plattform für Entwickler genutzt wird. GitHub ist das Facebook für Entwickler. Andere Dienste werden bei weitem nicht so genutzt.

Git, Mercurial, Subversion & Co besitzen einen gravierenden Nachteil: sie verwalten lediglich Dateien. Für eine strukturierte Softwareentwicklung sind aber noch weitere Werkzeuge notwendig. Um gefundene Fehler, neue Ideen oder Aufgaben zu verwalten, ist ein sog. Ticketsystem notwendig. Entwicklungsnahe Dokumentation wird in einem Wiki abgelegt, damit diese Texte unabhängig vom Programmcode bleiben und besser zugreifbar sind. Ein externes oder internes Blog zur Kommunikation ist ebenfalls hilfreich. Übrigens, diese Werkzeuge sind nicht nur zur Entwicklung von Software hilfreich.

Subversion als zentralistisches System kann dazu gut mit einer ergänzenden Software betrieben werden. Ich selbst habe dazu schon Trac verwendet. Git und Mercurial sind Beispiele für verteilte Systeme. Das erleichtert das entkoppelte Arbeiten und erhöht (im Prinzip) die Ausfallsicherheit. Trotzdem bieten Dienste wie GitHub keinen verteilten Zugriff auf Ticketsystem, Wiki & Co. Fällt GitHub (oder ein vergleichbarer Dienst) aus, stagniert die Entwicklung. Das macht die technische und organisatorische Umsetzung eines verlässlichen Vorgehens nicht einfach. Ein Ausfall von GitHub ist ähnlich relevant wie ein Ausfall von Facebook oder Twitter.

Nun kommt Fossil ins Spiel. Fossil ist ebenfalls eine Software zur Versionsverwaltung. Fossil bietet aber auch ein Ticketsystem, ein Wiki, ein Blog. Jeder Nutzer kann wählen, Fossil eher zentralistisch oder eher verteilt einzusetzen. Leider gibt es so gut wie keinen zentralen Hosting-Dienst, wie es GitHub oder andere sind. Dafür kann man es einfach als CGI-Programm auf einem Web-Server zum Laufen bringen. Der Web-Hoster muss lediglich das Kopieren und Aktivieren eines Programm erlauben. Meiner tut das (und viel mehr). Die Unterstützung für Fossil ist bei vielen Diensten sehr dürftig, immerhin unterstützt es ein Plugin meines Lieblings-Editors. Dafür bietet es einen eingebauten Web-Server, mitsamt optionaler Benutzerverwaltung.

Ich nutze inzwischen Fossil aus vielen Gründen.

Fossil ist sehr einfach in Betrieb zu nehmen. Im einfachsten Fall muss dazu eine Datei, die Software selbst, kopiert werden und mittels einigen wenigen Befehlen auf der Kommandozeile/Eingabeaufforderung funktioniert alles. Damit habe ich eine Versionsverwaltung, ein Ticketsystem, ein Wiki und mehr installiert. Bei Git, Mercurial, Subversion & Co benötige ich dazu wesentlich mehr, sofern ich ein privates Projekt verwalten möchte. Bei öffentlichen Projekte, zum Beispiel Open Source, muss ich wenigstens die Software mitsamt notwendiger Zusatzsoftware aufwendig installieren. Aber das macht man ja nur einmal pro Rechner.

Die Projektverwaltung ist mit Fossil sehr einfach. Zum einen besteht ein Projekt (bei Versionsverwaltungen heißt es genauer: Repository) bei Fossil aus einer einzigen Datei. Die kann ich einfach sichern und wiederherstellen. Bei Git, Mercurial, Subversion & Co sind das mindestens so viele Dateien, wie ich Dateien versionieren möchte. Zum anderen kann ich einfach von einem anderen Rechner benötigte Dateien holen. Das geht bei Mercurial ähnlich einfach. Bei Git und Subversion muss ich geeignete Infrastruktur bereitstellen.

Fossil ist ein System, das revisionssicher Daten speichert. Bei Git ist es recht einfach, die Historie eines Projektes zu verändern. Bei Mercurial ist es etwas schwerer, ebenso bei Subversion. Mit Fossil muss ich mir keine Sorgen machen, dass ich nicht aus Versehen etwas lösche. Alles bleibt verlässlich erhalten. Mit Fossil habe ich in 6 Jahren keine einzige Information verloren. Bei den anderen Systemen möchte ich nicht zählen, wie häufig da etwas passiert ist. Erst letzte Woche erreichte mich eine Mail von Studierenden, die in einer Projektstudie Probleme haben, weil die Historie versehentlich geändert wurde.

Sowohl auf der Kommandozeile, als auch über die projektspezifischen Web-Seiten kann ich meine Projekte gut verwalten. Die Kommandozeile bietet (fast) alle Möglichkeiten von Git & Co, und das auf eine benutzerfreundliche Weise. Die Web-Seiten sind ausreichend, vollständig konfigurierbar.

Fossil wird hauptsächlich von dem Entwickler als Open-Source-Projekt vorangetrieben, der auch für SQLite verantwortlich ist. SQLite ist die verbreitetste Datenbanksoftware. Sie findet sich unter Android, iOS, OSX, Firefox und viel mehr. Fossil basiert intern auf SQLite, umgekehrt wird Fossil für die Entwicklung von SQLite verwendet. Eat your own dog food.

Seit, einen Moment, 2004 Tagen betreibe ich ein internes Repository, in dem ich alle relevanten Informationen für mein digitales und mein Arbeitsleben ablege (ich musste nur kurz die entspreche Web-Seite mit den Statistiken des Repositorys aufrufen). Dazu betreibe ich einen kleinen Server, damit eine Version des Repositorys immer online ist. Der Server hat mehrfach gewechselt, das Repository nicht. Gesichert wird das Repository jede Nacht, verschlüsselt auf einen weit entfernten Server. Sobald ich einen neuen Rechner in Betrieb nehme (in den 2004 Tagen sind es mehr als 10 gewesen, aktuell sind 4 aktiv), muss ich Fossil auf den Rechner bringen, das Repository vom kleinen Server kopieren und es aktivieren. Fertig. Sollte der kleine Server ausfallen habe ich aktuell 3 weitere, gleichberechtigte Kopien, zuzüglich der Sicherungskopie.

Was verwalte ich in diesem Repository? Alle relevanten Dateien, zum Beispiel Vorlesungsunterlagen, dieses Blog, einige selbstgebaute interne Werkzeuge, Informationen über meine diversen Accounts, sowie meine Aufgabenliste. Diese habe ich über konfigurierbare Reports als eine Art Kanban-Prozess organisiert. Alles war nicht tagesaktuell erledigt werden muss, verwalte ich hier. Habe ich eine Information, eine Aufgabe hinzugefügt oder aktualisiert, muss ich als Befehl nur fossil sy eingeben und alles ist synchronisiert. Melde ich an einem meiner Rechner an, gebe ich fossil up ein, um diesen auf den aktuellen Stand zu bringen. So einfach ist das.

Inzwischen verwalte ich auch einige meiner Open-Source-Projekte mit Fossil. Git ist für meinen Workflow nicht so angemessen. Nicht vergessen: Git wurde realisiert, um die Entwicklung von Linux mit über 15 Millionen Zeilen Quelltext und Tausenden von Entwicklern zu unterstützen. Git muss ganz andere Bedürfnisse erfüllen, als ich mit meinen eigenen Projekten habe. Ob ich froh wäre, wenn Hunderte von Entwicklern an meine Projekte arbeiten, muss ich noch entscheiden. Unabhängig davon kann ich neue Projekte mit Fossil sehr schnell bereitstellen, einfacher als mit GitHub. Ich überlege aber, ob ich das eine oder andere Projekt nicht auf GitHub spiegeln soll. GitHub als soziales Netz für Entwickler.

Die von Fossil verwalteten Dateien lassen sich übrigens sehr leicht nach Git konvertieren. Das gilt leider nicht für die Tickets/Aufgaben und das Wiki. Trotzdem ist das eine gute Option für die Zukunft.

Fossil ist das Werkzeug meiner Wahl zur Versions- und Aufgabenverwaltung. Es integriert alle notwendigen Tätigkeiten, ist einfach zu installieren und zu betreiben, lässt sich einfach vernetzen, erlaubt zentrales und verteiltes Arbeiten und ist sehr robust und verlässlich.

Einfach mal ausprobieren.

Update 12.10.15: kleines Fundstück, das zeigt, was Git, Mercurial, Subversion für Sicherheitsprobleme haben. Fossil ist kaum anfällig: Die Git-Stolperfalle: Viele Webseiten geben sensible Daten preis.