Self-Publishing-Tipps: Versioning rulez!

tl:dr

Hallo liebe Self-Publisher, denkt ihr eigentlich nur an eure Verkaufszahlen oder verschwendet ihr ab und zu auch einen Gedanken an die Nachwelt – will heißen an die armen Literaturwissenschaftlerinnen, die eure Werke einmal erforschen müssen? Wenn euch der Nachruhm wichtig ist, solltet ihr diesen unermüdlich emsigen Wissenschaftlerinnen entgegenkommen, indem ihr die Entstehungsgeschichte eurer Werke protokolliert.

Einige von euch schreiben vielleicht Tagebuch und vermerken darin die Anzahl der Anschläge, die sie geschafft haben. Andere, und das werden die meisten sein, fertigen in regelmäßigen Abständen Sicherheitskopien ihrer Werke an und archivieren sie auf CD. Anhand dieser Sicherheitskopien können die Literaturwissenschaftlerinnen der Zukunft die Entstehung eurer Werke rekonstruieren, falls es dann noch CD-Laufwerke gibt. Sie werden dabei wichtige Erkenntnisse gewinnen: Zum Beispiel, dass die krause Vampirgeschichte eigentlich ein Schlüsselroman über eure Arbeitskollegen ist.

Backups sind gut, aber Versionierung ist etwas anderes. Was schreibt Wikipedia dazu?

»Eine Versionsverwaltung ist ein System, das zur Erfassung von Änderungen an Dokumenten oder Dateien verwendet wird. Alle Versionen werden in einem Archiv mit Zeitstempel und Benutzerkennung gesichert und können später wiederhergestellt werden. Versionsverwaltungssysteme werden typischerweise in der Softwareentwicklung eingesetzt um Quelltexte zu verwalten. Versionsverwaltung kommt auch bei Büroanwendungen oder Content-Management-Systemen zum Einsatz.«

Erfassung von Änderungen, Zeitstempel, Benutzerkennung – mehr braucht die Literaturwissenschaftlerin nicht, um die Entstehung eurer Romane zu rekonstruieren. Und ihr könnt dank der Versionsverwaltung jederzeit eine ältere Version eures Textes anschauen und prüfen, ob die allererste Fassung der Mordszene, die ihr mehrmals überarbeitet habt, nicht doch die beste war.

Versionsverwaltungssysteme werden in der Softwareentwicklung eingesetzt, aber es gibt sie auch bei Büroanwendungen. In LibreOffice findet man sie unter dem Menüpunkt ›Versionen‹. Dort kann man den aktuellen Stand des Dokuments als neue Version abspeichern, ältere Versionen ansehen oder ältere mit der aktuellen Version vergleichen.

Das ist schon nicht schlecht. In dem Kreativ-Schreibprogramm Scrivener heißt die Versionsverwaltung Snapshot. Das klingt bescheidener und gibt die Wahrheit auch besser wieder. Diese Versionsverwaltungen in Textverarbeitungen sind keine vollwertigen Systeme, sondern nette kleine Features.

Wer die ersten drei Folgen dieser Artikelserie gelesen hat, weiß, dass ich das Textformat Plain Text (einfachen Text) bevorzuge. Die im Wikipedia-Zitat erwähnten Quelltexte der Softwareentwickler sind solche Dateien im Plain-Text-Format. Man kann sie wunderbar mit einem professionellen Versionierungsprogramm verwalten.

Ich bin lange Zeit ohne Versionsverwaltungssysteme ausgekommen, bis zu dem Zeitpunkt, als ich zum Co-Autor eines Software-Buches wurde. Wenn zwei Personen an einem Buch schreiben, spielen Versionsverwaltungssystem ihre ganze Stärke aus, denn mit ihrer Hilfe lassen sich nicht nur Änderungen nachvollziehen, sondern auch Textstände synchronisieren.

Immer dann, wenn mehrere Personen an einem Buch arbeiten, solltet ihr euch überlegen, ob ein Versionsverwaltungssystem hilfreich sein kann. Dabei ist es egal, ob mehrere Autoren an einem Buch arbeiten oder ob Lektoren und Korrektoren zeitnah an der Entstehung eines Buches mitwirken sollen.

Dropbox und ähnliche Online-Speichersysteme können auch helfen, Textstände synchron zu halten, aber sie sind nicht so leistungsfähig wie echte Versionsverwaltungssysteme. Es sind lediglich gemeinsam genutzte Ordner, in denen schnell Unordnung herrscht, wenn sich nicht alle Beteiligten ungeheuer diszipliniert verhalten. Und welcher Autor tut das schon?

Wenn ich bei Projekten die Mitarbeit anderer Autoren einplane, pflege ich sie von Anfang an in einem Versionsverwaltungssystem, auf das man online zugreifen kann. Das Plone Benutzerhandbuch, das ich in der letzten Folge erwähnt habe, verwalte ich beispielsweise mit der Versionsverwaltung Bazaar. Da das Buch unter einer Creative-Commons-Lizenz vertrieben wird, ist das Archiv öffentlich zugänglich. Die Entwicklungsgeschichte des Buches findet man hier. Co-Autoren können sich den ›Quellcode‹ des Buches herunterladen, Änderungen vornehmen und die Änderungen an die Versionsverwaltung übergeben.

Was zwischen zwei Autoren funktioniert, ist auch zwischen zwei Rechnern möglich. Textfassungen auf zwei Rechnern können über die Versionierung immer synchron gehalten werden.

Dieser Seiteneffekt war für mich schließlich ausschlaggebend,  meine Buchprojekte mit einem Versionsverwaltungssystem zu pflegen. Denn seitdem ich regelmäßig abwechselnd mit Notebook und Desktop-Rechner arbeite, stellt sich für mich das Problem, die beiden Rechner zu synchronisieren. Es gibt dafür zwar Tools wie rsync oder Unison, die ich auch guten Gewissens empfehlen kann, aber diese Werkzeuge verhalten sich zu einer Versionskontrolle wie ein Hammer zu einem Werkzeug-Set für Feinelektroniker. Was passiert zum Beispiel, wenn man in einer Datei sowohl auf dem Notebook als auch auf dem Desktop Änderungen vorgenommen hat, also die Dateien auf beiden Rechnern geändert wurden. Unison zeigt in einem solchen Fall an, dass es zu einem Konflikt kommt und man sich für eine der beiden Versionen entscheiden muss. Bei einer Versionsverwaltung kann man beiden Versionen zusammenführen und so die Konflikte auflösen. Ein solcher Versionskonflikt ist schnell passiert, wenn man seinen Arbeitsrechner häufig wechselt. Und wenn mehrere Personen an einem Text arbeiten, ist das vorprogrammiert.

Wie muss man sich nun die Arbeit mit einer Versionsverwaltung vorstellen? Nehmen wir an, wir haben einen Ordner auf dem Desktop, in dem ein Roman entstehen soll. Wir öffnen die Konsole und wechseln in den Ordner.

$ cd MeinRoman

In dem Ordner befinden sich die Kapitel des Romans in einzelnen Textdateien.

kap01.txt kap02.txt kap03.txt

Nun erzeugen wir ein Mercurial-Archiv und sagen dem System, dass die Dateien mit der Endung .txt versioniert werden sollen.

$ hg init

$ hg add *.txt

Zum Schluss übergeben wir alles an das System:

$ hg commit -m "Die ersten drei Kapitel"

Mit -m fügen wir der Übergabe einen Vermerk hinzu. Jedesmal, wenn wir Änderungen übergeben, können wir einen Vermerk dazu schreiben.

Nun wechseln wir den Rechner und setzen uns vor das Notebook. Von dort können wir nun das Repository auf dem Desktop klonen, d.h. wir können eine vollständige Kopie des Verzeichnisses ‘MeinRoman’ in einem beliebigen Ordner anfertigen.

hg clone ssh://ich@desktop.local/MeinRoman

Um diesen Befehl ausführen zu können, muss auf beiden Rechnern die Secure Shell (ssh) installiert sein.

Wenn man den Befehl aufruft, loggt sich das Programm als Benutzer ‘ich’ auf dem Rechner ‘desktop’ im lokalen Netzwerk ein. Für ‘ich’ muss man natürlich seinen Benutzernamen auf dem Desktoprechner einsetzen und statt ‘desktop’ schreibt man den Namen des Rechners. Die Secure Shell fragt anschließend nach dem Passwort des entsprechenden Benutzers. Nach Eingabe des Passworts wird das Verzeichnis geklont. Es wird ein Ordner mit dem Namen ‘MeinRoman’ angelegt, der die gleichen Dateien enthält, wie der Ordner auf dem Desktop-Rechner.

Wir öffnen nun eine Datei und ändern den Text. Anschließend übergeben (commit) wir die Änderung an das System und schieben (push) die Änderung zurück auf den Desktop.

$ hg commit -m "Kapitel drei geändert"

$ hg push

Dann gehen wir zurück an den Desktop und bemerken, dass dort die Änderung scheinbar gar nicht angekommen ist, denn kap03.txt ist unverändert.

Das liegt daran, dass der Ordner mit den sichtbaren Dateien nicht das eigentliche Repository ist, sondern eine Arbeitskopie. Das Repository befindet sich in einem versteckten Ordner, den man auf MAC OS X und Linux mit dem Befehl ’ls -a’ sichtbar machen kann.

ls -a

hg kap01.txt kap02.txt kap03.txt

In dem unscheinbaren Ordner ‘.hg’ verbirgt sich das Repository. Um die Änderungen aus dem Repository in das Arbeitsverzeichnis zu bekommen, muss man dieses aktualisieren (update).

hg update

Mit diesem Befehl wird die Änderung aus dem Repository in die Arbeitskopie übertragen.

Nun ändern wir am Desktop Kapitel 2, übergeben die Änderung an die Versionsverwaltung und wechseln erneut ans Notebook. Dort gehen wir in den Ordner ‘MeinRoman’ und ziehen (pull) uns die Änderungen vom Desktop.

hg pull

In der täglichen Arbeit benötigt man nur die Befehle ‘commit’, ‘push’, ‘pull’ und ‘update’. Das prägt sich schnell ein.

Wenn man ein Repository auf einem Server im Internet einrichtet, kann man nicht nur mehrere Rechner synchronisieren, sondern erhält auch gleich ein Backup an einem entfernten Ort. Man kann dafür den eigenen Server nutzen oder den Dienst eines Unternehmens, das darauf spezialisiert ist, Code zu verwalten. Hier sind zum Beispiel GitHub und Bitbucket zu nennen. Code ist nichts anderes als Text und beide Anbieter verwalten auch LaTeX- und Sphinx-Repositories.

Bitbucket bietet registrierten Benutzern die Möglichkeit unbegrenzt private Repositories anzulegen. Private Repositories können von anderen Personen nicht eingesehen werden. Da Bitbucket von einer US-Firma betrieben wir, hat die NSA Zugriff auf das Repository. Das sollte man wissen. Ein Roman über einen Terroranschlag in den USA könnte unangenehme Folgen haben.In den USA macht man sich schon verdächtig, wenn man Finnegans Wake Ausschnitte per E-Mail versendet.

Bitbucket und GitHub haben dafür ein paar nette Features. So ist es möglich, die Texte online im Browser zu lesen – und zu bearbeiten. Sporadische Mitarbeiter müssen sich also nicht einmal mit der Bedienung einer Versionkontrolle auseinandersetzen. Wenn man mit Sphinx arbeitet, wie ich es in der letzten Folge beschrieben habe, dann zeigen Bitbucket und GitHub die Texte bereits in gerenderter Form an.

Bei einem meiner aktuellen Projekte sieht das so aus:

Ob man Git, Mercurial oder Bazaar wählt, ist Geschmackssache. Bei allen Programmen handelt es sich um ein so genannten Verteiltes Versionsverwaltungsystem (engl. Distributed Version Control System, Abk. DVCS). DVCS haben viele Vorteile und sind bei der Entwicklung von Open-Source-Software mittlerweile der Standard.

Mit einem Versionsverwaltungssystem gewinnt man mehr Kontrolle über den Entstehungsprozess seiner Werke. Die Nachwelt wird jubeln und künftige Literaturwissenschaftlerinnen finden ein weites Feld für ihre Forschungen vor.