KONZEPT:
RCS - Revision Control System
Diese Hilfe behandelt ein Verfahren welches nur fuer
Erzmagier zugaenglich ist.
GRUNDGEDANKE:
Mit dem 'Revision Control System' wird der Kernteil der Mudlib verwaltet.
Dieses System ermoeglicht es Aenderungen an Dateien wieder rueckgaengig
zu machen, Aenderungen nachzuvollziehen und zu dokumentieren.
Eine Einfuehrung in RCS erhaelt man unter Linux mit 'man rcsintro'.
Es ist fuer jede Datei der Mudlib wuenscheswert, dass man auch nach
einem Jahr noch nachvollziehen kann, was wann und warum an der Datei
geaendert wurde. Ausserdem moechte man manchmal insbesondere nach
einer Zeitspanne von Tagen die vorherige Version einer Datei wieder-
herstellen, da sich die Aenderung als instabil o.ae. erwies.
Diese Ziele koennen wir mit RCS erreichen. RCS hat ein Archiv aller
Dateien und davon wieder jeder Version. Man kann nun leicht neue
Versionen hinzufuegen, alte Versionen wiederherstellen oder die
Differenzen zwischen Versionen betrachten.
Das Archiv vom RCS wird manchmal auch 'Repository' genannt. Waehrend
das Archiv von anderen Versionskontroll-Systemen irgendwo 'zentral'
liegt, ist es bei uns verteilt. Das bedeutet, dass das Archiv direkt
im Verzeichnisbaum der Mudlib liegt. Dazu dienen die Unterverzeichnisse
mit dem Namen 'RCS'. In diesen befinden sich jeweils die Archive fuer
die Dateien, die im aktuellen Verzeichnis sind. RCS-Archive haben die
Endung ',v' (Komma Vau).
Beispiel:
/std/thing.c
/std/RCS/thing.c,v
/std/thing/description.c
/std/thing/RCS/description.c,v
Neben dem Archiv gibt es auch noch die 'echten' Dateien, wie thing.c
im obigen Beispiel. Diese Dateien sind alternativ
- eine Revision der Datei
- eine Arbeitskopie der Datei
Wenn die Datei das 'nur lesen' Atrribut gesetzt hat, so ist es eine
Revision der Datei. Fuer die meisten Dateien ist dies so, und zwar
speziell die neueste Revision der Datei. Schliesslich arbeitet an
den meisten Dateien niemand und man moechte das Mud mit den neuesten
Versionen laufen lassen.
Wenn die Datei 'les- und schreibbar' ist, so handelt es sich um eine
Arbeitskopie. Arbeitskopien sind immer einer bestimmten verantwortlichen
Person zugeordnet, die alleinig dort Aenderungen vornehmen darf. Nach
getaner Arbeit wird diese Person die Arbeitskopie zu einer neuen
Version der Datei erklaeren. Sie wird dann wieder 'nur lesbar'.
Den Lesestatus kann man mit 'll' bzw 'ls -l' sehen, 'rw' ist lesen
und schreiben, 'r-' ist nur lesen. Hat man eine Datei mit Les- und
Schreibrechten, so ist immer Vorsicht geboten, da die Datei (normaler-
weise) die Arbeitskopie einer anderen Person darstellt.
Die Unterscheidung zwischen Arbeitskopie und (wie man sagt) ausge-
checkter Revision liegt darin, dass man nur und ausschlisslich an
Arbeitskopien Aenderungen vornehmen darf. Weiterhin ist eine
Arbeitskopie auch immer einer bestimmten Person zugeordnet
Zusammenfassung:
- Es gibt ein verteiltes Archiv in RCS Unterverzeichnissen
- 'Echte' Dateien sind entweder Revision oder Arbeitskopie
- Arbeitskopien sind les- und schreibbar
- Arbeitskopien sind einer Person zugeordnet
- Es gibt immer nur eine Arbeitskopie, also kann auch immer nur
eine Person zur Zeit an einer Datei arbeiten
TYPISCHE AKTION:
Eine typische Aktion, wie man ihr tagtaeglich begegnet ist zum Beispiel
das Beheben von Schreibfehlern in einer der Mudlib-Dateien. Wir nehmen
man einen Fehler in der Datei /std/thing.c an.
Zunaechst wechseln wir in das Verzeichnis
$ cd ~/mudlib/std
Jetzt erzeugen wir eine Arbeitskopie der fraglichen Datei fuer uns.
$ co -l thing.c
RCS/thing.c,v --> thing.c
revision 1.13 (locked)
done
Man sieht an den Meldungen, dass die Datei neu aus dem Archiv in die
aktuelle Datei bewegt wurde, und dass es sich um die Revision 1.13
handelt. Das 'locked' besagt, dass die Datei fuer ausschliessliche
Bearbeitung durch uns gesichert ist. Andere Leute koenne nicht an
derselben Datei (genauer: Revision) arbeiten.
Wichtig ist hierbei zu bedenken, dass tatsaechlich eine neue Datei
aus dem Archiv erstellt wird. Hatte die aktuelle thing.c Aenderungen,
die dem RCS nicht bekannt waren, so sie diese nun unwiederbringlich
verloren.
Nun kann man die Datei (die als Arbeitskopie les/schreibbar ist) bear-
beiten und den Typo beheben. Nach dem Testen der Datei sagt man dem
RCS dann, dass die aktuelle Arbeitskopie eine vollwertige neue Revision
darstellt, und dass man die Arbeit abgeschlossen hat:
$ ci -u thing.c
RCS/thing.c,v <-- thing.c
new revision: 1.14; previous revision: 1.13
enter log message, terminated with single '.' or end of file:
>> _
Man sieht, die aktuelle Datei soll ins RCS-Archiv verschoben werden
(Beachte den Pfeil zwischen den Dateinamen in der ersten Zeile jeweils).
Dabei wird eine neue Revisionsnummer vergeben.
Nun gibt man an, was und/oder warum man etwas an der Datei geaendert
hat, also zB:
>> Typo in der Standardbeschreibung
>> .
done
Nach der Eingabe eines einzelnen Punktes (wie im Mud-Maileditor) gilt
die Meldung als abgeschlossen und das Einchecken wird durchgefuehrt.
Die Angabe von '-u' bewirkt, dass die Datei nach der Aktion 'unlocked'
ist, also wieder durch die Bearbeitung fuer alle freigegeben. Sie
erhaelt auch wieder den nur-lese-Status.
GEBRAEUCHLICHE AKTIONEN:
Hier werden jetzt alle Aktionen vorgestellt, von denen mir bekannt ist,
dass sie bei uns benutzt werden.
Zunaechst allgemein fuer alle Kommandos gibt es folgende Schalter:
-l Lock. Vergibt ein Lock auf die Datei an den aktuellen Benutzer.
-u Unlock. Entfernt ein Lock.
-r1.1 Revision 1.1. Macht etwas mit der angegebenen Revision.
Kommandos:
co = Check out. Holt die Datei neu aus dem Archiv.
Dabei wird eine eventuell vorhandene Arbeitskopie ueberschrieben!
co -l name.c Man erhaelt eine Arbeitskopie der Datei und setzt
gleichzeitig das Lock fuer einen selbst. Wenn
eine Arbeitskopie (oder allgemein eine schreib-
bare Datei) schon existiert, so wird eine Warnung
erzeugt. Hat eine andere Person ein Lock auf die
Datei, so ist die Aktion unmoeglich (s.u.).
co -u name.c Holt die letzte Archivversion aus dem Archiv ohne
ein Lock auf uns zu setzen (bzw unser Lock wird
entfernt). Ist gebraeuchlich um alle Aenderungen
die man gemacht hat zu verwerfen (aufgeben ;o)
co -u -r1.1 name.c Holt die spezifizierte Revision aus dem Archiv.
Wenn man eine alte Revision ansehen moechte.
Achtung, sie liegt am Platz der normalen Datei,
so dass man sie i.A. umbewegen und die aktuelle
Version danach auschecken wird.
ci = Check in. Legt eine neue Version ins Archiv.
Die Aktion ist nur moeglich, wenn man ein Lock auf die aktuelle
(im allgemeinen: eine) Revision der Datei hat.
ci -u name.c Die neue Version ins Archiv legen und dabei unser
Lock entfernen. Dies ist die gebraeuchlistste
Aktion.
ci -u -r2.0 name.c Die neue Revision erhaelt die Nummer 2.0 anstatt
einer fortlaufenden Nummerierung. Kann man
benutzen um totales Neuschreiben anzuzeigen.
rlog = Archivverlauf anzeigen.
Mit 'rlog name.c' bekommt man eine Liste aller Kommentare zu
allen Revisionen. In der Datei selbst lassen wir ja in der Regel
nur die letzten 2 bis 3 Stueck stehen. Hier kann man alten
Veraenderungen nachspueren.
Ausserdem wird angezeigt, wer eine Datei gelockt hat. Dies ist
interessant wenn man eine schreibbare und veraenderte Arbeitskopie
einer Datei findet und den 'Schuldigen' finden moechte.
rcsdiff = Unterschiede aufzeigen.
Mit diesem Kommando kann man Unterschiede zwischen Revisionen oder
Revisionen und der aktuellen Arbeitsdatei anzeigen.
rcsdiff -r1.2 -r1.3 name.c Vergleicht Revision 1.2 und 1.3
rcsdiff -r1.2 name.c Vergleicht Revision 1.2 mit Arbeitsdatei.
rcsdiff name.c Vergleicht hoechste Rev. mit Arbeitsdatei.
Dies sollte man immer machen, wenn man eine schreibbare Datei findet.
Hier kann man dann sehen, ob sie nur faelschlich schreibbar gesetzt
ist, oder ob jemand schon daran gearbeitet hat. Weiterhin sollte
man mit rlog auf eventuelle Locks von einer anderen Person schauen.
Weiterhin ist es nuetzlich um Aenderungen nachzuvollziehen. Also
'Was haben wir eigentlich damals mit Rev 1.14 genau geaendert?'
-> rcsdiff -r1.13 -r1.14 name.c
rcs - Allgemeine RCS Steuerung.
Hiermit kann man direkt das Archiv und die Locks beeinflussen.
rcs -l name.c Setzt ein Lock auf die aktuelle Revision fuer
uns, ohne die Arbeitsdatei zu veraendern (sie
bleibt auch zB nur-lesbar).
rcs -u name.c Entfernt ein Lock von der Datei. Ist das Lock
nicht von uns, so werden wir gewarnt und
wird aufgefordert einen Begruendungstext an-
zugeben, der an den Lockbesitzer gemailt werden
wird. Das mit der Mail funktioniert aber eh nicht.
rcs -o1.1 name.c Entfernt Revision 1.1 unwiederruflich aus dem
Archiv (o wie obsolete). Meistens wird es
auf die hoechste Revision angewandt, wenn man
entdeckt, dass man etwas vergessen hat und
dies nachbessern will ohne noch eine neue
Revision anzulegen (siehe Beispiel unten).
rcs2log
Wird eigentlich nicht direkt benutzt (ausser von Gum, ich weiss
nicht wozu er das benutzt?).
Wird indirekt benutzt ueber:
updatelogs
Erstellt in den grossen RCS kontrollierten Verzeichnisen jeweils
eine 'Changelog' Datei. Also zB mudlib/std/Changelog.
In diesen Dateien sind alle geaenderten Files mit Aenderdatum und
Begruendungstext aufgelistet.
updatelogs zeigt an, welche Changelogs ueberhaupt Aenderungen
erfahren haben. ('No changes to ...').
Dies kann man nach einer groesseren Aktion nutzen um nochmals
alle Aenderungen, die man ausgefuehrt hat, schnell anzuzeigen.
So vergisst man keine Dateien in der Updates-Rubrik.
Die Changelog-Dateien selbst sind auch manchmal nuetzlich ;o)
WAS NUN:
Was nun, wenn wir eine Datei bearbeiten wollen, aber es wird gemeldet,
dass eine schreibbare Version der Datei schon existiert oder jemand
anderes ein Lock auf die Datei hat?
Wenn wir nicht wissen wieso das der Fall ist: erstmal abbrechen.
Sprich auf die Frage 'overwrite' mit 'no' antworten. Dann
kann man mit rcsdiff schauen, ob die Datei sich vom Archiv unter-
scheidet. Wenn nein: Alles nicht so schlimm. Vielleicht hat jemand
die Datei gelockt und dann nicht bearbeitet/vergessen. Mit rlog
schauen ob sie gelockt ist (steht ganz oben, man verwendet also
zweckmaessigerweise 'rlog name.c | less'). Ist sie gelockt, die
Person ansprechen und/oder das Lock manuell (rcs -u) entfernen.
Unterscheidet sich die Datei jedoch vom Archiv, so schauen wir auch
wer die Datei gelockt hat. Die Person ansprechen und ums einloggen
bitten. Oder es selbst tun. Hierzu muessen wir erst das Lock der
anderen Person entfernen (rcs -u) und dann fuer uns ein Lock
setzen (rcs -l) (die Arbeitsdatei wird durch beide Befehle ja nicht
beeinflusst). Nun koennen wir sie normal einchecken (ci -u) unter
unserem Namen. Im Kommentar sollte man den Originallocker angeben.
("Eingecheckt, hatte Gum vergessen. Aenderungen waren: ...")
Unterscheidet sich die aktuelle Datei vom Archiv aber niemand hat
die Datei gelockt... tja, dann ist guter Rat schwer. Hier sollte man
beruecksichtigen von wann die Datei ist (haben wir damit schon
rebootet, laeuft sie also ok oder ist sogar erforderlich?). Meistens
ist dies der Fall. Dann die Revision manuell einchecken (rcs -l und
dann ci -u). Vielleicht hat aber auch jemand eine alte Revision
zum Ansehen ausgecheckt (Dateikopf beachten), dann sollte man sie
einfach mit der aktuellen Version ueberschreiben (co -u).
LOGNAME:
Bislang verschwiegen wurde der Mechanismus, mit dem der Name der
Person ermittelt wird, die die RCS-Aktion durchfuehrt (und dann ja
auch im Log auftaucht oder bei 'rlog' als Locker.
Der Name der Person muss in der Umgebungsvariablen $LOGNAME stehen.
Dieser wird normalerweise automatisch beim Einloggen gesetzt,
zusammen mit dem $PROMPTNAME. Wenn also dein Prompt am Hurrikap
in der Art "Fini@hurrikap:~>[41] " aussieht, wurdest du korrekt
erkannt und auch der LOGNAME entsprechend gesetzt.
Wenn nicht, so sollte man ~mud/.tcshrc entsprechend erweitern.
Manuell geht es mit zB 'setenv LOGNAME Gum'.
SIEHE AUCH:
Hilfeseite zum RCS: rcsintro(1), ci(1), co(1), rcs(1), rcsdiff(1),
rlog(1)
|
