RCS (Revision Control System)
RCS ist eine Alternative zu etckeeper
.
Das Revision Control System (RCS) ist eine Software zur Versionsverwaltung von Dateien auf dem Computer. Es dient speziell bei Textdateien wie Quelltexten, Konfigurationsdateien oder Dokumentationen der Verwaltung und Dokumentation der Änderungen.
RCS verwaltet einzelne Dateien und kann daher nicht oder nur bedingt zur Verwaltung von ganzen Projekten verwendet werden.## Initialisierung ##
Soll eine neue Datei mit RCS verwaltet werden muss diese zunächst mit RCS bekannt gemacht werden.
rcs -i $dateiname
Hiermit wird für $dateiname eine $dateiname,v erstellt, in der alle Revisionen mit ihren Metadaten gespeichert werden.
Wichtig: Dieser Schritt ist obsolet, eine neue Datei kann einfach per ci
eingecheckt werden.## Platzhalter ##
Eine Datei die mit RCS verwaltet wird kann Platzhalter beinhalten, diese werden beim checkin entsprechend befüllt:
Author : $Author$
Date : $Date$
Header : $Header$
Id : $Id$
Locker : $Locker$
Log : $Log$
Revision: $Revision$
Source : $Source$
State : $State$
Jede mit RCS verwaltete Datei sollte einen entsprechenden Header aufweisen, auch damit jeder Bearbeiter der Datei sofort erkennt dass sie per RCS verwaltet wird.
Die Platzhalter können entweder direkt in der Datei eingesehen oder mit dem Befehl ident $dateiname
ausgelesen werden. Der Platzhalter $Log$
fügt das komplette Changelog in die Datei ein, dies ist eigentlich nicht notwendig, da hierfür rlog
genutzt werden kann. Um die Datei klein zu halten kann auf $Log$
also verzichtet werden.
Außerdem sollten die Zeilen natürlich als Kommentar eingefügt werden:
# $Header$
# $Locker$
# $Id$
# $Source$
# $Date$
# $Author$
# $Revision$
# $State$
Das Ergebnis kann dann wie folgt aussehen:
# $Header: /etc/postfix/main.cf,v 1.2 2012/03/15 10:51:06 root Exp root $
# $Locker: root $
# $Id: main.cf,v 1.2 2012/03/15 10:51:06 root Exp root $
# $Source: /etc/postfix/main.cf,v $
# $Date: 2012/03/15 10:51:06 $
# $Author: root $
# $Revision: 1.2 $
# $State: Exp $
Der Wert von $State$
kann beim checkin über den Parameter ci -s
festgelegt werden, folgende Werte sind gültig:
- Exp (Experimental, standard)
- Stab (Stable)
- Rel (Released)## rmcedit/mkrcs ##
Um die Verwaltung zu vereinfachen ist auf allen Servern das Script rmcedit
verfügbar:
# /usr/bin/rmcedit
#!/bin/bash
mcedit ${1}
ci ${1}
co -l ${1}
Es öffnet mcedit mit der angegebenen Datei, checkt diese ein und gelockt wieder aus.
Wird eine Datei zum ersten Mal mit RCS bearbeitet sollte rmcedit nicht verwendet werden, weil sonst die erstmaligen Änderungen an der Datei nicht wieder rückgängig gemacht werden können. Stattdessen sollte mkrcs
verwendet werden:
# /usr/bin/mkrcs
#!/bin/bash
mcedit ${1}
sed -i '3i # $Header$\n# $Locker$\n\n# $Id$\n# $Source$\n# $Date$\n# $Author$\n# $Revision$\n# $State$\n' ${1}
ci ${1}
co -l ${1}
Das Script fügt auch automatisch den RCS-Header an den Anfang der Datei ein (3. Zeile). Hierbei ist zu beachten, dass ``# als Kommentarkennzeichner verwendet wird. Verwendet die Datei ein anderes Format ist dies nachträglich zu ändern.
Da der Header in der dritten Zeile (um #!/bin/bash nicht zu zerstören) einfügt ist ggf. auch hier Nacharbeit nötig.## checkin ##
Um die Datei in der derzeitigen Fassung zu versionieren dient folgender Befehl:
ci $dateiname
Hiermit wird eine neue Version (oder die erste Version nach der Initialisierung) gespeichert.## checkout ##
Soll eine Datei geändert werden, so ist sie zunächst auszuchecken:
co -l $dateiname
Durch das -l
wird die Datei bis zum nächsten Checkin gesperrt, so dass kein anderer Benutzer die Datei bearbeiten kann.
Wichtig: Es ist wichtig eine Datei VOR jeder Änderung (auch durch Debian-Tools wie z.B. dpkg-reconfigure
) ausgecheckt werden, damit alle Änderungen in die Versionierung eingecheckt werden können. Ansonsten gehen beim nächsten Checkout alle nicht eingecheckten Änderungen verloren.## diff ##
Mit rcsdiff
können Unterschiede zwischen zwei Versionen angezeigt werden:
rcsdiff -r1.1 -r2.1 -u $dateiname
Hier wird die Revision 1.1 (also die erste versionierte Fassung der Datei) mit der Revision 2.1 verglichen. Das -u
sorgt dafür dass Änderungen immer im jeweiligen Kontext angezeigt werden.## rlog ##
Mit rlog $dateiname
kann die Historie einer Datei mit den dazugehörigen Kommentaren eingesehen werden. Dies ist hilfreich um zwei miteinander zu vergleichende Revisionen ausfindig zu machen.## Ablauf ##
Der typische Ablauf bei der Verwendung von RCS sieht wie folgt aus:#= Neue Datei #=
- anlegen der Datei (z.B. touch test.txt)
- einfügen des RCS-Headers (siehe Platzhalter) und ggf. weiterer Inhalte
- einchecken der Datei
ci test.txt
- auschecken und locken der Datei
co -l test.txt
Solange die Datei nicht wieder ausgecheckt wurde existiert nur die Revisionsdatei test.txt,v
nicht die test.txt
. Dieses Verhalten hat vor und Nachteile. Grundsätzlich ist es gut die Livedaten als gelockte, ausgecheckte Dateien im System zu haben, da so vor einer Änderung ein Checkin erfolgen muss und so keine Änderungen verloren gehen können. Greift jedoch ständig z.B. ein PHP-Script auf eine Config-Datei zu wäre es natürlich fatal wenn diese zeitweise fehlen würde. In einen solchem Fall ist die Datei per ci -u test.txt
einzuchecken. Nach der Bearbeitung sollte die Datei dann aber trotzdem mit co -l test.txt
wieder gelockt werden.#= Bestehende Datei #=
Eine bestehende Datei sollte gelockt sein. Ist dies nicht der Fall muss sie zunächst eingecheckt und erneut (mit lock) ausgecheckt werden.
- prüfen ob Lock vorliegt (
ident test.txt
)- falls kein Lock: einchecken der Datei (
ci test.txt
bzw.ci -u test.txt
) - falls kein Lock: auschecken der Datei (
co -l test.txt
)
- falls kein Lock: einchecken der Datei (
- ändern der Datei
- einchecken der Änderungen (siehe oben)
- auschecken und locken
Das Vorgehen wirkt zunächst umständlich stellt aber sicher, dass keine Änderungen verloren gehen, falls nach einer vorhergehenden Änderung vergessen wurde die Datei einzuchecken.