Versionsverwaltung (1)
Während des Lebenszyklus eines Softwareprojektes ändert sich der Programmcode laufend. Tools zur Versionsverwaltung, wie RCS und CVS, helfen hier den Überblick zu behalten.
Ein Tool zur Verwaltung mehrerer Versionen von Textdateien und Programmcode ist das Revision Control System RCS. Es steht unter der GNU Public License (GPL) und ist für alle Unix- und Windows-Plattformen verfügbar. Es zeichnet sich durch eine einfache Bedienbarkeit aus. Sein bevorzugter Einsatzbereich ist dort, wo es um die Versionsverwaltung einzelner Dateien geht. Zum Beispiel könnte es für den Autor eines solchen Artikels, wie Sie gerade lesen, wichtig sein, die Änderungshistorie beim Entstehen und Publizieren seines Artikels nachvollziehen zu können.
Dazu wird im Verzeichnis, in dem die Datei versions.html mit dem Text des Artikels steht, ein Unterverzeichnis RCS angelegt:
mkdir RCS
Nun kann die Textdatei eingecheckt werden:
ci versions.html
Das ci (CheckIn) Kommando erzeugt im Verzeichnis RCS eine RCS-Datei, speichert versions.html als Version 1.1 in ihr und löscht versions.html im aktuellen Verzeichnis. Außerdem wird der Benutzer nach einer Beschreibung - etwa "Artikel zur Versionsverwaltung mit rcs" - gefragt, die zusammen mit der Datei abgespeichert wird.
Um die Datei jetzt wieder in das normale Arbeitsverzeichnis zu bekommen, muss sie ausgecheckt werden:
co versions.html
Die Datei kann jetzt zwar betrachtet und publiziert, jedoch nicht verändert werden, da sie vom CheckOut-Kommando co read-only angelegt wurde. Um sie weiter bearbeiten zu können, muss eine Sperre (ein "Lock") auf die Datei gesetzt werden:
co -l versions.html
Jetzt kann versions.html weiter bearbeitet und verändert werden. Die Differenzen zur vormals eingecheckten Version 1.1 können jederzeit mittels
rcsdiff versions.html
ermittelt werden.
Ist der Benutzer mit seinen Änderungen zufrieden, kann er erneut
ci versions.html
aufrufen. Die Datei bekommt jetzt Version 1.2, eine kurze Beschreibung dessen, was sich geändert hat - das "Log" - kann (und sollte!) dabei vom Benutzer eingegeben werden.
Während der Bearbeitung der Datei - also nachdem co -l eine Sperre gesetzt hat - können andere Benutzer sich diese Datei zwar ansehen, jedoch nicht editieren. Jeder Versuch, mit co -l auszuchecken, endet in der Meldung, dass versions.html zur Bearbeitung gesperrt ist. So wird vermieden, dass mehrere Autoren gleichzeitig die Datei editieren können und dann beim Abspeichern die Änderungen eines anderen überschreiben. Das heißt aber auch, dass bei Beteiligung mehrerer Autoren am Artikel immer nur einer aktiv sein kann - während der eine arbeitet, müssen alle anderen pausieren. Bei großen Softwareprojekten, an denen viele Programmierer beteiligt sind, kann es auf diese Weise schnell zu Deadlocks kommen: Jeder wartet auf den anderen, ohne selbst voranzukommen.
Beim Einsatz von RCS für die Softwareentwicklung taucht noch eine weitere Schwierigkeit auf: Umfangreiche Programme bestehen typischerweise aus vielen einzelnen Programmcode-Dateien. Wird das Programm dann in Version 1.0 ausgeliefert, heißt das mitnichten, dass auch alle Programmcode-Dateien automatisch die RCS-Version 1.0 haben. Ja, diese müssen noch nicht einmal alle die gleiche Version haben, da es ja im Ermessen der Entwickler liegt, wie oft eine Datei ein-/ausgecheckt wird und damit eine neue Versionsnummer bekommt! Das macht es ohne weitere Maßnahmen fast unmöglich, nach einer gewissen Zeit noch nachvollziehen zu können, aus welchen RCS-Versionen welcher Dateien denn die Programmversion 1.0 erzeugt wurde.
Abhilfe bietet hier der Einsatz des Concurrent Versions System CVS. Eine Einführung in dieses doch schon komplexere System folgt im zweiten Teil dieses Artikels.