Teamwork

Sei es die Studienarbeit, ein Vortrag, Buch, Artikel oder Programmierprojekt – wenn man über längere Zeit an einem (Quell-)Text arbeitet, kommt früher oder später der Tag, an dem man sich wünscht, den letzten Montag gelöschten Abschnitt doch wieder zurückholen zu können. Doch gelöscht ist gelöscht, und wer nimmt sich dann nicht vor, es nächstes Mal besser zu machen?

Versionskontrolle im Kleinen …

Wer allein arbeitet und einigermaßen Durchhaltevermögen hat, fängt möglicherweise an, sich die letzte Version (z.B. kursskript-2.tex) zu Beginn einer Arbeitsrunde in eine neue Datei mit fortlaufender Nummer (kursskript-3.tex) zu kopieren. Welche Version die von letztem Montag war, bekommt man aus der Datumsangabe heraus, die ls -l kursskript* als letztes Änderungsdatum angibt.

Warum dann nicht gleich den Datumsstempel mit im Dateinamen verpacken? Mit date liefert ein Unixsystem die aktuelle Datums- und Zeitangabe schließlich frei Haus, und mit den rückwärts zeigenden Hochkommata kann man die Shell dazu bewegen, zuerst das darin enthaltene Kommando auszuführen und das Ergebnis im Gesamtkommando zu verwenden:

[trish@lillegroenn answergirl]$ cp kursskript.tex kursskript`date`.tex
 cp: copying multiple files, but last argument (2001.text) is not a directory
 Try `cp --help' for more information.

cp beschwert sich darüber, dass wir mehr als eine Datei kopieren wollen und das letzte Argument 2001.tex kein Verzeichnis sei (denn in eine einzelne normale Datei kann man nicht mehrere Quelldateien kopieren). 2001.tex? Das sieht doch aus wie ein Bestandteil der date-Ausgabe:

[trish@lillegroenn answergirl]$ date
 Mon Mar 12 02:24:09 CET 2001

Damit fällt es uns wie Schuppen von den Augen: Die Leerzeichen zählen für die Shell natürlich als Trennzeichen zwischen Argumenten, bei cp also Dateinamen. Mit Gänsefüßchen lässt sich die bash allerdings davon überzeugen, dass die Leerzeichen zum Argumentstring gehören:

[trish@lillegroenn answergirl]$ cp kursskript.tex "kursskript`date`.tex"
 [trish@lillegroenn answergirl]$ ls -l kursskript*
 -rw-r--r--  1 trish  users  8967 Mar 12 02:25 kursskript.tex
 -rw-r--r--  1 trish  users  8967 Mar 12 02:34 kursskriptMon Mar 12 02:34:04 CET 2001.tex

Der Nachteil dabei: kursskriptMon Mar 12 02:34:04 CET 2001.tex sieht nicht nur hässlich aus, dank der Leerzeichen im Dateinamen wird die Datei uns mehr als einmal dazu zwingen, ihren Namen in der einen oder anderen Kommandozeile in Hochkommata zu setzen. Lieber wäre uns also ein Dateiname à la kursskript_dd_mm_yy.tex – oder damit die Dateien auch immer schön in der dem Kalender folgenden Reihenfolge in der ls-Ausgabe auftauchen – kursskript_yy_mm_dd.tex.

Wie ein Blick in die date-Manpage verrät, geht auch dies: Wir müssen date lediglich hinter einem Plus die gewünschten Formatplatzhalter mit auf den Weg geben:

[trish@lillegroenn answergirl]$ mv "kursskriptMon Mar 12 02:34:04 CET 2001.tex" kursskript_`date +%y_%m_%d`.tex
 -rw-r--r--  1 trish  users  8967 Mar 12 02:25 kursskript.tex
 -rw-r--r--  1 trish  users  8967 Mar 12 02:34 kursskript_01_03_12.tex

… und für die weniger Gewissenhaften

Sie fühlen sich schon jetzt nicht mehr wohl bei soviel Dran-Denken-Müssen? Da sind Sie nicht die/der Einzige. Erst recht, wenn's darum geht, mit Co-Autor(inn)en an einem Manuskript zu arbeiten, wird es nicht nur mit der Disziplin schwierig, sondern auch mit dem Abgleichen. Wer garantiert mir schließlich, dass meine Co-Referentin die gestern eingebauten Tippfehler nicht schweigend in ihrer Version beseitigt, während ich die Sätze eben dieses Kapitels in der meinigen gänzlich umstelle?

Nicht nur, um die Arbeitsroutine zu vereinfachen, sondern auch um Mehrarbeit zu vermeiden, gibt es hier nur eins: Ein professionelles Versionsmanagement muss her. Wenn Sie mit Office-Paketen o.ä. arbeiten, die Ihre Arbeit in proprietären Binärformaten (wie StarWriter) abspeichern, werden Sie vermutlich auf die hoffentlich eingebaute Versionskontrollfunktion zurückgreifen. ASCII-Texte hingegen lassen sich spielend mit Versionsmanagern verwalten, wie sie in großen Programmierprojekten eingesetzt werden. (Der Quellcode in einer Programmiersprache ist schließlich auch nichts anderes als Text.)

Die Recherche ergibt erstaunlich wenig Auswahl. Während Firmen noch eher das kommerzielle Perforce (http://www.perforce.com/) lizensieren werden (Open-Source-Projekte können eine kostenlose Lizenz anfordern; die voll funktionsfähige Evaluationsversion lässt nur Zwei-Mann/Frau-Projekte zu) greifen nicht nur Gelegenheitsversionskontrollierer/innen zumeist auf das altgediente Concurrent Versions System cvs zurück.

Das wird auch von den meisten Distributionen mitgeliefert. Wer auf seinen CDs oder dem FTP-Server des Distributors kein passendes Paket findet, steuert am besten http://rpmfind.net/linux/rpm2html/search.php?query=cvs oder für den Sourcecode http://download.cyclic.com/pub/ an.