Backstage #3: Versionieren selbst­geschriebener Texte

14.02.2012 | #Backstage

Ich hatte bereits angemerkt, dass mir das Versionieren und die Nachvollziehbarkeit aller Änderungen beim Schreiben meiner Dokumente sehr wichtig sind. In diesem Backstage-Artikel möchte ich meinen Ansatz dazu vorstellen.

Verwendung findet dazu bei mir das Tool Subversion (kurz SVN), das starke Verbreitung in der Softwareentwicklung genießt, wo es primär zur Verwaltung von Source Code dient. Ich möchte hier nicht darauf eingehen, warum ich gerade SVN und nicht Alternativen wie CVS oder Git verwende, so gut wie alles hier gesagte geht mit anderen Systemen auch. Mir geht es darum zu unterstreichen, dass ein Versionierungstool auch für Autoren sehr hilfreich sein kann.

Wie funktioniert das also grob:

  • Man legt einmalig ein s.g. SVN-Repository an. Das ist nichts anderes als ein Verzeichnis, in dem sich SVN austoben kann, und in dem es alles merkt, was es zum Versionieren von Dateien benötigt. Da drinnen wird man niemals direkt was ändern können oder wollen. SVN macht diese Versionen halbwegs intelligent, und kopiert nicht einfach alles zig-fach, sondern erstellt Delta-Dateien, aus denen es bei Bedarf die einzelnen Versionen rekonstruieren kann.
  • Mit dem SVN-Programm macht man dann ein „checkout“, um eine (meist die aktuelle) Version in ein Arbeitsverzeichnis zu übernehmen, editiert das dort nach Lust und Laune, und wenn man fertig ist, macht man mit dem SVN-Programm wieder ein „commit“, und alle Änderungen im Arbeitsverzeichnis werden zurück in das Repository übernommen.
  • SVN selbst ist ein unsichtbares Kommandozeilenwerkzeug, das man selten direkt nutzt, sondern über das Tool seiner Wahl oder die Integration im Lieblingseditor nutzt. Wie bequem und übersichtlich das ist, hängt daher davon ab, wie gut das Tool/der Editor ist, nicht wie gut SVN ist. Mein Editor (Eclipse - stelle ich getrennt noch mal vor), ist für Programmierer gedacht die Source Code bearbeiten, und entsprechen tiefgehend ist dort die Integration der SVN-Funktionen. (Unter Windows gibt es z.B. aber auch ein Plugin für den Explorer, wo man versionierte Ordner wie ganz normale Ordner auch per Rechtsklick-Menüs bearbeiten kann.)
  • Um zu Versionieren muss ich nicht viel tun, bloß 1x am Tag nach getaner Arbeit einen Commit-Button zu drücken, und darf für diese Tagesversion ("Sub-Version"), sogar noch einen Kommentar erfassen, damit ich nach einer Woche noch grob weiß, was die Montag-Änderung und was die Dienstag-Änderung war. Natürlich steht es mir frei, in längeren oder kürzeren Intervallen so eine Unterversion zu „commiten“, ich gehe für diesen Artikel mal von Tagesversionen aus. Jede dieser Tagesversionen bekommt automatisch eine eigene (fortlaufende) Nummer, und kann optional auch mit einem Namen versehen werden. Ich habe also viel mehr Tagesversionen, als ich z.B. ROBiN PDFs publiziere. Zwischen einer v0.3 und einer v0.4 könnten dann z.B. 42 Tagesversionen liegen.

Welche allgemeinen Vorteile habe ich nun, wenn ich Subversion benutze:

  • Das Offensichtliche zuerst: SVN protokolliert im Hintergrund was ich schreibe in diesen Tagesversionen. Jedes neue Komma wird registriert, jede Leerzeile die ich wieder lösche, alle Änderungen am Layout (weil die in LaTeX ja in Textform passieren und nicht in Dialogfeldern).
  • Mit diesen Tagesversionen kann man nun allerhand anstellen. Ich kann nachsehen, wie sich mein heutiger Stand vom dem von gestern unterscheidet. Ich kann genauso einfach nachsehen, wie sich mein heutiger Stand von dem vor zwei Monaten und drei Tagen unterscheidet, oder ich kann das SVN fragen, was eigentlich ROBiN v0.3 von v0.4 über diese 42 Tagesversionen unterschieden hat, obwohl ich gerade an v0.6 werke. In meinem Editor wird das auch hübsch dargestellt, mit den zwei Versionen nebeneinander und farblich markierten Änderungen in den zwei Dateien. Sehr praktisch, wenn man in einem LaTeX-Makro, das „eben noch funktioniert hat“, die fehlende Klammer sucht, die man unabsichtlich gelöscht hat.
  • Ich kann die Änderungen nicht nur anzeigen lassen, sondern in der Zeit hin- und herspringen. SVN stellt mir auf Wunsch den Tagesstand vom 23.05.2010 wieder her, dann den vom Jahr davor, und dann wieder den aktuellen. Das kann ich auf Datei-, Ordner- oder Gesamtebene machen. Damit kann ich z.B. ein altes PDF nochmal generieren, und muss mir nicht alle PDFs aufheben.
  • SVN versioniert über alle Ordner im Arbeitsverzeichnis hinweg und merkt sich, welche Dateien für so ein einzelnes Tageswerk zusammen gehören. Damit sehe und vergleiche ich Änderungen an allen Dateien der jeweiligen Version, was bei LaTeX sehr praktisch ist, wenn man aus Bequemlichkeit nicht in einem riesigen .tex-File arbeiten möchte. SVN merkt sich, wann welche Dateien dazu gekommen sind, und sogar wann Dateien oder Ordner gelöscht oder umbenannt wurden. Springe ich in der Zeit zurück, stellt es alle Dateien und Ordner wieder her, die es zu diesem Zeitpunkt noch gegeben hat.
  • SVN ist mir unmittelbar nicht im Weg. Ich habe meinen normalen Ordner (das Arbeitsverzeichnis) auf der Platte, in dem sich meine LaTeX-Dateien befinden, und die ich mit dem Editor meiner Wahl ganz normal bearbeite. Mit dem SVN interagiere ich nur, wenn ich commite oder in den Versionen springe. SVN zwingt mir auch kein bestimmtes Tool auf.

Welche besonderen Vorteile habe ich, wenn ich SVN für LaTeX bzw. für Rollenspiele benutze:

  • Die Verfolgung von Änderungen über alle Dokumente ist extrem hilfreich, wenn man Regeln ändert. Ich sehe nämlich, was ich am Tag, an dem ich damals eine Regel erfunden habe, noch alles geändert habe, z.B. sich auf die Regel beziehende Beispiele später im Text, oder darauf aufbauende Sonder-/Ausnahmeregeln. Die möchte ich dann ja ggf. auch mit ändern. (Wenn man klug ist, macht man ein commit nicht am Ende des Tages, sondern am Ende jeder zusammengehörigen Änderung, u.U. halt mehrfach pro Tag - dann fällt das Nachvollziehen noch leichter. SVN wird nicht langsamer, nur weil viele Versionen da sind. Ich habe beim Programmieren schon mit langjährigen Mega-Repositores gearbeitet mit Commits/Versionsnummern im 6-stelligen Bereich.)
  • Ich brauche mir keine Sorgen zu machen, Texte oder Layoutelemente zu löschen. Wenn etwas gerade unwichtig ist - raus damit. Sollte ich das nochmal benötigen, kann ich im SVN den gelöschten Text wieder finden, und muss nicht in einem Notizfile das für den Fall des Falles aufheben.
  • Im LaTeX-Umfeld ein praktischer Nebeneffekt: das Layout ist ja auch in Text definiert, also sehe ich genauso einfach wie ich Fließtext- und Regeländerungen verfolgen kann auch, wann ich welche Layoutänderungen wo gemacht hab, seit wann z.B. die Tabelle blau ist oder die Hervorhebungen fett statt kursiv. Oder welche Texte ich gekürzt habe, damit sie sich nach einem Layoutwechsel wieder auf eine Seite passen.
  • Ich kann von unterschiedlichen PCs aus arbeiten. Gehe ich auf Reisen, mache ich das check-out eben auf den Notebook. Komme ich wieder zurück, commite ich vom Notebook in das SVN, und hole die Änderungen - mit der selben Protokollqualität wie sonst auch - auf den Stand-PC.

Dann gäbe es noch Vorteile, die ich gar nicht nutze, die aber für Autoren interessant sein könnten:

  • SVN ist ja eigentlich für Teams gedacht, die gemeinsam an Projekten (Source-Code) arbeiten. Ich arbeite nur am Stand-PC ODER am Notebook, aber natürlich könnte ein Autorenteam, das gemeinsam an einem Setting arbeitet, gleichzeitig arbeiten und ihre Änderungen in ein gemeinsames SVN commiten. Das SVN kümmert sich dann darum, das alles in einen Stand zusammenzuführen, und nur wenn zwei Personen zeitgleich am selben Absatz gearbeitet haben, ist ein manuelles Abgleichen nötig. Und auch dann hilft SVN mit, indem es die fraglichen Passagen im Text mit Klammern markiert, damit man leicht weiß, zwischen welchen Sätzen man sich entscheiden muss.
  • Es ist möglich, an zwei Versionen von einem Dokument getrennt weiter zu arbeiten, ohne dass die sich stören. Beispiel TRiAS: Sagen wir mal, ich bin mit v1.0 fertig. Dann kann ich so einen s.g. „Branch“ auslösen, und habe nun zwei Versionsstränge im System: v1.0 und sagen wir mal „aktuell“. Zwischen denen kann ich nun hin und her schalten. Am v1.0-Strang mache ich Änderungen, wenn Errata auftauchen und ich ein v1.0.1 benötige. Am „aktuell“ Strang beginne ich das Regelwerk komplett umzubauen, weil in einer v2.0 ja alles neu und besser werden soll. Jeder Strang hat nun eine eigene Historie, und ich kann innerhalb derer vor und zurück springen.
  • SVN ist so weit verbreitet, da kann man bei vielen Anbietern im Internet hosten lassen, meist kostenlos wenn man an freien Projekten arbeitet, und für wenig Geld für abgesicherte Accounts. Man kann also auf das Repository daheim verzichten, wenn man die Administration scheut.

Zwei Nachteile möchte ich aber nicht unerwähnt lassen:

  • SVN kann nur bedingt in Binärdateien wie z.B. Bilder hineinsehen. Es versioniert die zwar genauso wie alle anderen Dateien, tut das aber, indem es jedes mal eine neue Kopie davon macht wenn sich was ändert. D.h. wenn man ein Bild oft ändert, entsprechend viel Plattenplatz verbraucht wird.
  • Wenn man ein SVN-Repository auf der eigenen Platte führt, belegt ein Projekt natürlich dann doppelt Platz: einmal das Arbeitsverzeichnis, in dem das LaTeX Projekt liegt, und dann noch einmal im SVN-Repository, dem Verzeichnisbaum, in dem sich das SVN seine internen Notizen ablegt, um alle Versionen wiederherstellen zu lassen. Mit heutigen Platten ist das aber zu vernachlässigen. Mein LaTeX-Arbeitsverzeichnis hat ca. 50MB an Daten, das Repository ist nach etwa 1,5 Jahren nun auf 300MB gewachsen - und geschätzte 90% davon wegen der Bilder.

Der Artikel kratzt natürlich nur an der Oberfläche, aber vieleicht hat er Lust gemacht, sich SVN mal näher anzusehen oder bei einem der kostenlosen SVN-Hostern mal ein Test-Repository anzulegen und ein kleines Dokument dort testweise abzulegen. So findet man IMHO am einfachsten heraus, ob diese Art der Versionierung einem bei eigenen Rollenspielprojekten weiter hilft.