© Ivan Kokoulin / 123RF.com

Was kommt nach Git? Den Pijul-Machern zufolge ihre von Grund auf neu entwickelte Versionsverwaltung. Die mixt alte Ideen pfiffig neu zusammen. Reicht das für ein “Post-Git”?

Der vorwiegend in Mexiko lebende Riefenschnabelani ist ein Vogel, der seine Nester gemeinschaftlich in kleinen Gruppen errichtet. Während die possierlichen Tierchen hierzulande einen wahren Zungenbrecher als Namen tragen, nennen ihn die Mexikaner kurz und bündig Pijul. So heißt auch eine recht junge Versionsverwaltung, die Pierre-Étienne Meunier und Florent Becker ins Leben gerufen haben [1]. Wie der Riefenschnabelani fokussiert sie auf verteilte Arbeit im Team. Außerdem geht sie äußerst flott zu Werke, lässt sich einfach bedienen und räumt mit einigen Problemen des Platzhirschs Git auf. So lauten zumindest die vollmundigen Versprechen der Macher.

Auf den ersten Blick wirkt die Arbeit mit Pijul tatsächlich erstaunlich simpel: Nachdem Sie sämtliche Dateien über »pijul add *« bei der Versionsverwaltung angemeldet haben, teilen Sie dem Werkzeug jede Änderung via »pijul record« mit. Das war auch schon alles. Anders als bei Git gibt es keine verwirrende Staging-Area, zudem fallen die Befehle deutlich schlanker aus als beim großen Konkurrenten.

Dabei arbeitet Pijul genauso verteilt: Jedes Teammitglied besitzt sein eigenes lokales Repository, in dem sich die Versionsverwaltung alle Änderungen des entsprechenden Autors merkt. Der Datenaustausch zwischen den Teammitgliedern ist mit Pijul ebenfalls ein Klacks. Möchte die Programmiererin Alice einen Bugfix von ihrem Kollegen Bob übernehmen, holt sie über das Kommando »pijul pull« die entsprechende Codeänderung in ihre Kopie. Selbst wenn Bob in der Zwischenzeit eifrig weitergearbeitet hat, kann sich Alice via »pijul pull« bequem den Bugfix herauspicken. Das beschriebene Cherry Picking erfordert in Git und Co. teilweise arge Verrenkungen.

Sperrige Schnappschüsse

Git und viele andere bekannte Versionsverwaltungssysteme schießen regelmäßig Schnappschüsse vom jeweils aktuellen Arbeitsfortschritt. Jeder dieser Snapshots baut auf dem vorherigen auf. Möchten Sie einen Schnappschuss wiederherstellen, benötigen Sie folglich zwingend dessen Vorgänger. Genau das erschwert wiederum das Cherry Picking. Bei Git fällt dann häufig ein Griff zu »git rebase« [2] oder »git rerere« [3] an. Das gilt insbesondere, wenn sich Alice häufiger ein paar ältere Kirschen bei Bob herauspicken möchte.

Die verteilte Arbeit führt außerdem zwangsweise zu Konflikten, beispielsweise wenn Bob dieselben Dateien bearbeitet wie Alice. Die Versionsverwaltungen versuchen zwar, die Dateiinhalte selbstständig zusammenzuführen, doch in einigen Fällen liegen sie bei diesem Merge daneben oder hinterlassen sogar verwürfelte Codezeilen [4]. Pijul geht deshalb einen anderen Weg, den sich Meunier und Becker von einem alten Bekannten abgeschaut haben.

Mathe-magisch

Bereits im Jahr 2003 und somit noch vor der Erfindung von Git veröffentlichte David Roundy die Versionsverwaltung Darcs [5]. Sie arbeitet nicht mit Snapshots, sondern verfolgt die einzelnen Änderungen in den Dateien. Das Repository speichert also nur noch Patches, von denen jeder eine ganz bestimmte Änderung an den eigentlichen Inhalten repräsentiert.

Das Vorgehen bringt gleich mehrere Vorteile mit sich. Zunächst spielt es keine Rolle mehr, in welcher Reihenfolge man zwei Änderungen ins eigene Repository übernimmt. Alice kann sich dementsprechend erst den Bugfix aus Bobs Repo holen und anschließend noch den Code für ein neues Feature – oder umgekehrt erst den Code übernehmen und daraufhin den Bugfix einspielen. In beiden Fällen erhält sie dasselbe Ergebnis (Abbildung 1). Wer sich noch an den Mathematikunterricht erinnert: Dort wird diese Eigenschaft als kommutativ bezeichnet.

Abbildung 1: Bei kommutativen Änderungen spielt es keine Rolle, ob Bob die Änderung von Alice übernimmt oder umgekehrt. Die Ergebnisse fallen jeweils identisch aus.

Darüber hinaus ist es unerheblich, ob Alice die beiden Änderungen nacheinander in ihren Quellcode integriert oder ob sie erst beide zusammenfasst und dann das Ergebnis in ihr Repo übernimmt. Die Änderungen sind folglich assoziativ (Abbildung 2). Das erlaubt, Änderungen schrittweise zu übernehmen, etwa im Rahmen eines Reviews. Die Assoziativität verhindert zugleich, dass die Versionsverwaltung die Codezeilen bei einem Merge durcheinanderwürfelt.

Abbildung 2: Assoziative Änderungen kann Alice entweder nacheinander von Bob übernehmen (oben) oder direkt zusammen. Das Ergebnis ist jeweils dasselbe.

Langsamer Opa

Diese netten Eigenschaften erleichtern das Cherry Picking und das Merging radikal. Da die Versionsverwaltung ausschließlich Quellcodeänderungen jongliert, vereinfacht sich ganz nebenbei die Bedienung. Gemeinerweise funktioniert das alles nur, wenn die einzelnen Änderungen tatsächlich vollkommen unabhängig voneinander sind. Zudem können weiterhin Konflikte auftreten, beispielsweise, wenn Alice und Bob dieselbe Zeile bearbeiten.

Diese Probleme erschlägt Darcs mit einer gehörigen Portion komplexer Mathematik. Die dabei notwendigen Rechnungen können selbst bei kleineren Codeänderungen mehrere Stunden dauern. Darcs arbeitet dadurch sogar langsamer als die meisten Pendants, obendrein skaliert die Versionsverwaltung recht schlecht.

Die Pijul-Entwickler übernehmen deswegen von Darcs lediglich das grundlegende Konzept. Die von Pijul verfolgten Änderungen verwaltet unter der Haube eine ausgeklügelte Datenstruktur, für die Abbildung 3 ein vereinfachtes Beispiel zeigt. Als Ausgangspunkt dient ein sogenannter Graph, der aus Knoten (die Kreise) und Kanten (die Pfeile) besteht. In diesem Gebilde merkt sich das Tool, welche Änderung wie viele Bytes an welcher Stelle modifiziert hat. Der Graph sieht zwar recht unübersichtlich aus, ist aber schnell erklärt.

Verknotete Kanten

Dort hat zunächst jemand eine leere Datei mit i Bytes gefüllt. Pijul nummeriert intern alle Änderungen durch, die erste erhält die Nummer 0. Die Informationen stopft Pijul in den Knoten ganz links in Abbildung 3, die Nummer der Änderung lautet C0. Das C steht für Change Number und soll in der Grafik lediglich bei der Unterscheidung der Knoten helfen. Im Knoten ist zusätzlich vermerkt, an welchen Positionen in der Datei sich etwas geändert hat (0 bis n-1). Die Datei wurde also am Anfang geöffnet, anschließend kamen n Bytes hinzu. Das Schreiben startete an der Position 0 und endete an der Position n-1.

Abbildung 3: Die Änderung C1 hat in der Datei an der Position p genau m Bytes einfügt.

Im nächsten Schritt wurden mitten in der Datei m weitere Bytes eingefügt. Die Änderung erhält die Bezeichnung C1 und fügt ab der Position p insgesamt m Bytes ein. Dazu trennt Pijul die Datei an dieser Position auf, klebt die neuen m Bytes ein und heftet am Ende wieder den Rest der ursprünglichen Datei an.

Aus der ersten Änderung C0 bleiben die ersten Bytes von der Position 0 bis p-1 erhalten. Dann folgen die m Bytes aus der zweiten Änderung C1, am Schluss stehen alle Bytes von der Position p bis n-1 aus C0.

Schatz, es ist ein CRDT

Zusätzlich gibt es noch eine Kante, die von der geänderten Datei zurück zu C0 führt. Dank ihrer Hilfe lässt sich sehr leicht die ursprüngliche Datei rekonstruieren. Das Löschen von Daten funktioniert ähnlich wie das gezeigte Einfügen, weitere Operationen sind nicht notwendig.

In Pijul ist die Datenstruktur allerdings etwas komplexer aufgebaut, als hier gezeigt. Unter anderem kann man darin ablesen, wann welcher Entwickler welche Zeilen modifiziert hat. Überdies kommt auch Pijul nicht um komplizierte Mathematik herum, etwa aus der Kategorientheorie. Das Ergebnis ist ein sogenannter Conflict-free Replicated Data Type (CRDT). Solche Datenstrukturen lassen sich auf verschiedene Rechner übertragen, wo die Anwender sie unabhängig von ihren Teamkollegen verändern können – genau das, was man für eine verteilte Versionsverwaltung benötigt.

Dank des cleveren Aufbaus ermöglicht das in Pijul nicht nur ein effizientes Cherry Picking, Sie können zudem lediglich einen Teil eines Repositorys in ein neues klonen (Partial Clones). Überdies besteht die Möglichkeit, zwei Repositories zu verschmelzen. Zu guter Letzt lassen sich selbst uralte Änderungen recht einfach zurücknehmen: Dazu genügt eine passende Änderung.

Hauseigenes Telefonbuch

Der Graph in Pijul enthält viele kleinteilige Informationen, wodurch er schnell ziemlich ausufert und somit nicht mehr komfortabel in den Hauptspeicher passt. Die Pijul-Entwickler mussten daher einen Weg finden, die Graphen möglichst effizient auf einem Datenträger zu speichern. Vor allem die Zugriffe auf die Inhalte sollten möglichst flott stattfinden.

Die Lösung fanden sie in einem Key-Value-Store, also einer Datenbank, die nur Schlüssel-Wert-Paare speichert. Von den vorhandenen Key-Value-Stores auf dem Markt erfüllte jedoch keiner die Anforderungen an die innovative Versionsverwaltung. Darum entwickelten die Pijul-Macher kurzerhand ihre eigene Datenbank. Das Ergebnis heißt Sanakirja, was im Finnischen “Wörterbuch” bedeutet. Laut den Messergebnissen des Pijul-Teams [6] soll Sanakirja schneller arbeiten als die bestehenden Alternativen Sled [7] und LMDB [8].

Fehlende Funktiönchen

Pijul startete anfangs als eine Art Experiment und Forschungsprojekt, selbst heute treibt lediglich ein kleines Team die Entwicklung voran. Das merkt man Pijul gleich an mehreren Stellen deutlich an. So lag die Versionsverwaltung zu Redaktionsschluss noch im Beta-Stadium vor, die erste stabile Version 1.0.0 befand sich allerdings bereits auf der Zielgeraden. Wichtige Projekte sollten Sie Pijul also derzeit noch nicht anvertrauen, obwohl die Versionsverwaltung in der Praxis bereits recht stabil läuft. Das Pijul-Team setzt sie erfolgreich bei der Entwicklung seiner eigenen Versionsverwaltung ein – Pijul versioniert sich damit gewissermaßen selbst.

Außerdem gibt es momentan noch einige offene Baustellen. Beispielsweise existiert bisher keine Möglichkeit für Tags, wie Git sie schon länger bietet und mit denen Sie unter anderem Beta-Versionen oder Release Candidates markieren können. Andere Features stehen zwar zur Verfügung, sind aber nicht gut getestet oder kaum erprobt.

So möchte man mitunter mehrere einzelne Projekte in einem riesigen Repository zusammenfassen. Solche Monorepositories haben sich beispielsweise bei Anwendungen bewährt, die aus zahlreichen Microservices bestehen. Pijul skaliert zwar laut seinen Entwicklern hervorragend und eignet sich damit prinzipiell für den Betrieb sehr großer Repos. Die Pijul-Macher weisen in ihren FAQ jedoch explizit darauf hin, dass sie auf den Betrieb eines Monorepositorys noch keinen Fokus gelegt haben. Es kann folglich funktionieren, muss es aber nicht, zumal die Versionsverwaltung derzeit keine darauf speziell abgestimmten Funktionen anbietet.

Dicke Dinger

Apropos groß: Pijul verarbeitet zwar auch sehr große Dateien, doch abhängig von den darin gespeicherten Daten klappt das Mergen nicht effizient. Das gilt zum Beispiel für große Videodateien. Aufgrund der Arbeitsweise der Versionsverwaltung müssen Sie allerdings nicht zwingend alle Bearbeitungsschritte der Dateien herunterladen. Ändert beispielsweise ein Videojournalist seinen Filmbeitrag vor der Abgabe mehrfach, muss der Kunde nicht auch noch diese Zwischenstände aus dem Pijul-Repository herunterladen.

Ein weiteres Problem entsteht, sobald Sie größere Änderungen an einem komplexen Projekt vornehmen. Das passiert schnell, wenn sich Styleguides ändern und Sie etwa sämtliche Funktionen in allen Quellcodedateien umformatieren. Dann entstehen zahlreiche Abhängigkeiten, die mit in das Repository wandern. Pijul-Anwender müssen also mitdenken und möglichst unabhängige Änderungen in die Versionsverwaltung schieben. Zum Beispiel könnte man jede Datei einzeln umformatieren und sie dann jeweils als eine eigene Änderung bei Pijul anmelden.

Inbetriebnahme

Falls Sie jetzt neugierig auf Pijul geworden sind, können Sie die Versionsverwaltung mit wenigen Handgriffen installieren. Alle dazu notwendigen Komponenten fasst der Kasten “Abhängigkeiten” zusammen.

Unter Debian und Ubuntu spielt das Kommando aus der ersten Zeile von Listing 1 das notwendige Zubehör ein. Stellen Sie danach mit dem Kommando aus der zweiten Zeile sicher, dass Sie ausschließlich die stabilen Rust-Werkzeuge verwenden. Pijul selbst richten Sie dann mit dem Befehl aus der dritten Zeile ein. Abschließend nehmen Sie noch den Pfad zum Programm »pijul« in die »PATH«-Variable auf (letzte Zeile).

$ sudo apt install make libsodium-dev libclang-dev pkg-config libssl-dev libxxhash-dev libzstd-dev clang rustup
$ rustup default stable
$ cargo install pijul --version "~1.0.0-beta"
$ export PATH="$PATH:$HOME/.cargo/bin/"

Einrichtung

Haben Sie schon einmal mit einer Versionsverwaltung und insbesondere mit Git gearbeitet, dürften Sie mit Pijul schnell warm werden. Zunächst wechseln Sie in das Projektverzeichnis mit den zu versionierenden Dateien und erzeugen dort mit dem Kommando »pijul init« ein neues Repository, das im neuen Unterverzeichnis ».pijul/« landet. Die Versionsverwaltung merkt sich bei jeder Änderung, welcher Autor sie vorgenommen hat. Damit das gelingt, müssen Sie zunächst via »pijul identity new« ein paar Informationen zu Ihrer Identität hinterlegen (Abbildung 4).

Abbildung 4: Nur mit einer Identität lassen sich Dateien mit Pijul verwalten, sonst verweigert die Versionsverwaltung den Dienst.

Sie dürfen den Befehl mehrfach aufrufen und so mehrere Identitäten anlegen, etwa für unterschiedliche Projekte oder Teams. Um die neue Identität von den anderen unterscheiden zu können, müssen Sie ihr im ersten Schritt einen eindeutigen Namen geben. Des Weiteren fragt Pijul Sie nach Ihrem Namen, Ihrer E-Mail-Adresse, ob diese Identität mit einem Passwort gesichert werden soll, ob die Identität an einem bestimmten Datum abläuft und ob sie mit einem Remote-Benutzerkonto verbunden werden soll. Die letzten drei Fragen können Sie jeweils mit nein beantworten.

Beim Erstellen der Identität erzeugt Pijul einen kryptografischen Schlüssel (Public Key), mit dem es jede Ihrer Änderungen signiert. Der Schlüssel identifiziert zudem immer eindeutig einen Autor und lässt sich nicht so leicht manipulieren wie ein Name oder eine E-Mail-Adresse.

Erste Schritte

Sobald Sie Ihre Identität hinterlegt haben, können Sie eine oder mehrere Dateien unter die Beobachtung von Pijul stellen. Für das Go-Programm »hello.go« lautet das entsprechende Kommando beispielsweise »pijul add hello.go«. Statt einer einzelnen Datei dürfen Sie auch mehrere oder gleich ein komplettes Unterverzeichnis angeben. Soll das Werkzeug dabei Dateien ignorieren, hinterlegen Sie deren Namen in der Textdatei ».ignore«.

Damit weiß Pijul zwar, welche Dateien es im Blick behalten soll, das Repository steht aber immer noch leer. Um es zu befüllen, tippen Sie in der Datei »hello.go« Ihren Quellcode ein und informieren Pijul über diese Änderung. Dazu genügt der Aufruf »pijul record«. Nach der Auswahl eines Texteditors öffnet dieser eine Ansicht mit zahlreichen Informationen über die Änderung (Abbildung 5). Hinterlegen Sie dort in den Anführungszeichen hinter »message =« einen Kommentar; im Beispiel lautet er »Initiale Fassung«. Speichern Sie das Dokument, und beenden Sie den Editor.

Abbildung 5: Mit dem Kommando »pijul record« sehen Sie alle Eckdaten einer Änderung ein und korrigieren sie gegebenenfalls. In der Regel ist das jedoch nicht notwendig.

Ab jetzt rufen Sie nach jeder Änderung an Ihren Dateien »pijul record« auf. Sämtliche Änderungen listet jederzeit »pijul log« auf (Abbildung 6). Via »pijul unrecord« lässt sich eine Änderung wieder zurücknehmen. Das ist besonders dann sinnvoll, wenn es gilt, Konflikte zu beheben. Das Kommando erwartet dabei als Parameter die recht kryptische Identifikationsnummer, die »pijul log« hinter »change« präsentiert. Welcher Entwickler welche Zeilen wann verändert hat, verrät »pijul credit« (Abbildung 7), das etwas netter formulierte Pendant von »git blame«.

Abbildung 6: Jede Änderung erhält eine eindeutige und kryptische Identifikationsnummer, die »pijul log« jeweils hinter »change« nennt.

Abbildung 7: Welcher Entwickler welche Zeilen wann verändert hat, verrät »pijul credit«.

Mit anderen arbeiten

Der Zugriff auf ein zweites Repository funktioniert ähnlich wie in Git. Zunächst klont der Befehl »pijul clone /home/tim/hallowelt« das Repository aus dem Verzeichnis »/home/tim/hallowelt/« in den aktuellen Ordner. Statt eines lokalen Repositorys dürfen Sie bei Bedarf eines via SSH (Listing 2, erste Zeile) oder HTTPS anzapfen (zweite Zeile).

$ pijul clone tim@myserver.de:pfadzum/repo
$ pijul clone https://myserver.de/pfadzum/repo

In einem der beiden Repositories erstellte Änderungen schieben Sie jetzt per »pull« in das andere oder holen sie umgekehrt mit »push« dorthin. Abbildung 8 zeigt dafür ein Beispiel: Dort klont Pijul das Repository im Verzeichnis »alice/« in das Verzeichnis »bob/«. Anschließend wird darin die Datei »hello.go« verändert. Diese Änderung schiebt »pijul push« zurück in das Repo in »alice/«. Beim »push« öffnet sich erneut ein Texteditor, in dem Sie die Einträge für die nicht zu übertragenden Änderungen löschen.

Abbildung 8: Pijul überträgt hier per »push« die Änderungen aus dem Verzeichnis »bob/« in das Repository im Verzeichnis »alice/«.

Kanäle

Auch nach dem Ausliefern eines fertiggestellten Programms läuft die Entwicklung normalerweise weiter, es kommen folglich munter weitere Änderungen hinzu. Allerdings wäre es gut zu wissen, welche Änderungen die im produktiven Einsatz befindliche Version der Anwendung bilden.

Für solche Zwecke bietet Pijul Channels, hinter denen schlicht eine Sammlung von Änderungen steckt. In der Praxis legen Sie zunächst einen Channel an, geben ihm einen eindeutigen Namen wie »stable« (Listing 3, erste Zeile) und schieben eine neue Änderung (zweite Zeile) hinein. Sie sparen Tipparbeit, indem Sie mit dem Kommando aus der dritten Zeile direkt in den Channel wechseln. Sämtliche Änderungen landen anschließend ohne Umwege in »stable«. Welche Channels existieren, verrät »pijul channel«.

$ pijul fork stable
$ pijul record --channel stable
$ pijul channel switch stable

In der Arbeitsweise ähneln die Pijul-Channels den Branches aus Git. Da sie aber aus einer Ansammlung von Änderungen bestehen, verhalten sie sich etwas anders. Vor allem existiert kein Kommando, das zwei Channels verschmilzt. Stattdessen ziehen Sie einfach die benötigten Änderungen aus dem Channel: Zunächst ermitteln Sie via »pijul log –channel stable« die Identifikationsnummer der letzten Änderung und wenden sie dann via »pijul apply ABC« an. »ABC« steht dabei für die Identifikationsnummer. Sämtliche Änderungen, auf denen diese letzte Änderung aufbaut, holt Pijul automatisch hinzu. Anders ausgedrückt: Das Rebase aus Git entspricht einem einfachen Merge in Pijul.

Schmiedekunst

Damit ist der Funktionsumfang von Pijul bereits fast komplett beschrieben. Falls Sie tiefer in das innovative Versionskontrollsystem einsteigen möchten, empfiehlt sich das sehr ausführliche Online-Handbuch [11]. Es stellt derzeit ohnehin die einzige Informationsquelle zu Pijul dar.

Dessen Entwickler verwenden übrigens häufig den Begriff Change synonym zu Patch. Und sie laden alle Interessierten zum Mitmachen ein: Pijul ist ein Open-Source-Projekt, der komplette Quellcode steht unter der GPLv2. Wer die für die eigentliche Arbeit zuständige Bibliothek Libpijul in eigene kommerzielle Programme integrieren möchte, kann bei den Pijul-Entwicklern eine passende Lizenz einholen.

Unter https://nest.pijul.com betreiben die Pijul-Entwickler den derzeit einzigen Hosting-Dienst für Pijul, der sich mehr als offensichtlich Github als Vorbild nimmt (Abbildung 9. Dessen Funktionsumfang erreicht das Nest genannte Cloud-Angebot zwar noch nicht, es erlaubt aber bereits Diskussionen und bietet grundlegende CI-Funktionen. Bis zu 1 GByte Speicherplatz gibt es in Nest kostenlos; wer mehr braucht, muss ein kostenpflichtiges Monatsabo abschließen.

Abbildung 9: Die Pijul-Macher betreiben einen eigenen kostenpflichtigen Hosting-Dienst für Pijul-Projekte, der sich an Github anlehnt und somit gleichzeitig an Programmierer richtet.

Fazit

Pijul vereint interessante Konzepte, lockt mit einer einfachen Bedienung und arbeitet bereits in der Beta-Version recht stabil. Der Versionsverwaltung fehlen allerdings im Gegensatz zu Git ein Ökosystem und eine große Community. Ob daher Pijul tatsächlich als “Post-Git” den Platzhirsch ablösen kann, dürfte maßgeblich davon abhängen, ob die Versionsverwaltung eine größere Community und Anwenderschaft aufbauen kann. Zu wünschen wäre es dem kleinen, flinken Underdog. (csi)