Bei der Entwicklung umfangreicherer Programme, und speziell bei der Optimierung, hat man oft das Problem, das man verschiedene Versionen seiner Programme aufbewahren möchte. Nun ist das mehrfache Speichern kompletter Pakete bei knappem Plattenplatz nicht sehr geschickt, außerdem auch nicht unbedingt sehr übersichtlich. Das Problem wird verschlimmert, wenn mehrere Leute an einem Programm arbeiten und sich bei gleichzeitigem Verändern ein wilder Versions-Verhau bildet.
Das Revision Control System (RCS) hilft dabei, hier die Übersicht zu bewahren. Es speichert in einem File die aktuelle Version, die sukzessiven Unterschiede zu früheren Versionen und zusätzliche Verwaltungs-Informationen. Außerdem kontrolliert es schreibende Zugriffe mehrerer Benutzer und sperrt gegebenfalls, um Inkonsistenzen zu verhindern.
Die grundlegende Bedienung ist sehr einfach: Zunächst werden zu allen
Source-Files die zugehörigen RCS-Files angelegt mit ''ci 
.f'' (ci = ''check
in''). Für jedes File foo.f wird dadurch eine RCS-Datei ''foo.f,v'' angelegt,
eine Kurzbeschreibung des Programms wird erfragt, die Versions-Nummer auf
1.1 gesetzt und das Original foo.f gelöscht. Die aktuelle Version wird
wieder herauskopiert mit ''co foo.f'' (co = ''check out'').
Nur die Source-Files werden editiert, nie die RCS-Files selbst. Checkt man eine neue Version ein (wieder mit ''ci foo.f''), wird die Versions-Nummer um eins erhöht (1.2, 1.3, ..). Bei jedem Einchecken wird noch ein Erklärungstext verlangt, der die Änderungen dieser Version kurz erläutern soll. Mit der Option -u kann man ein File einchecken, ohne daß es gelöscht wird, so daß man gleich damit weiterarbeiten kann. Eine neue Nummer kann man mit der Option -r angeben: ''ci -r2.1 foo.f''. Auch das Auslesen einer speziellen Version geht mit der Option -r: ''co -r1.3 foo.f''.
Um auch einem Source-File selbst ansehen zu können, zu welcher Version es
gehört, kann man an beliebiger Stelle (am besten am Anfang in einem
Kommentar) das Wort ''$Id$'' einfügen. Beim Einchecken wird es automatisch
durch die Versions-Nummer sowie weitere Informationen ersetzt.8
Auch die Zusammenarbeit mit make gestaltet sich sehr bequem, da meist
entsprechende Regeln schon vordefiniert sind: Ist zu einem zu erzeugenden
Object-File ein Source-File vorhanden, wird es kompiliert, ansonsten wird
es aus dem RCS-File herausgezogen, kompiliert und wieder gelöscht.
Um alle Files immer auf dem gleichen Versionsstand zu halten, auch wenn man
nur einige davon geändert hat, geht man am besten folgendermaßen vor: Im
Makefile definiert man eine Variable (z.B. SRC) mit den Namen aller
Source-Files und fügt ein Ziel source ein:
source:
co -r$(VERSION) $(SRC)
Mit ''make source'' holt man von allen Files die aktuelle Version heraus,
ändert und fügt dann alle wieder ein mit ''ci .f''. Einen vollständigen
Satz einer alten Version erhält man mit ''make VERSION=1.3 source''. Bei
größeren Programmprojekten wird man natürlich anders vorgehen und
verschiedene Versionen für verschiedene Teile vorsehen.
Mit dem Programm rlog kann man sich über den Inhalt des RCS-Files informieren, so gibt ''rlog foo.f'' u.a. eine Liste aller Versionen mit zugehörigem Erklärungstext aus. Den Unterschied zwischen zwei Versionen erhält man mit ''rcsdiff -rVERS1 -rVERS2 foo.f''.
Das Programm rcs dient zur direkten Manipulation von RCS-Files. U.a. kann man damit auf folgende Weise eine Version aus einem RCS-File streichen:
rcs -o8.15 foo.f
Über weitergehende Möglichkeiten von RCS, z.B. das Erstellen von
Verzweigungen im Versionsbaum, das Zusammenfaßen mehrerer Versionen zu
einer oder das Verhindern von gleichzeitigen Schreibzugriffen mehrerer
Benutzer auf ein File, informiert das Online-Manual unter den Stichworten
ci, co, ident, rcs, rcsdiff, rcsmerge und rlog.
