» SelfLinux » Programmierung » CVS » CVS für Fortgeschrittene » Abschnitt 2 SelfLinux-0.10.0
zurück   Startseite Kapitelanfang Inhaltsverzeichnis GPL   weiter

SelfLinux-Logo
Dokument CVS für Fortgeschrittene - Abschnitt 2 Revision: 1.1.2.8
Autor:  Karl Fogel
Formatierung:  Johnny Graber
Lizenz:  GPL
 

3 Watches: Wer arbeitet wann woran

Normalerweise behandelt CVS jede Arbeitskopie als isolierte »Sandbox1«. Niemand bekommt mit, was Sie an Ihrer Kopie bearbeiten, solange bis Sie Ihre Änderungen durch einen Commit freigeben. Umgekehrt wissen Sie nicht, was »die anderen« an ihrer Kopie tun, von den herkömmlichen Kommunikationsmitteln, wie »Hey, ich werde jetzt an parse.c arbeiten, sagt mir, wenn ihr etwas daran machen wollt, damit wir Konflikte vermeiden können!« den Gang runter zu brüllen, einmal abgesehen.

Dieses formlose Vorgehen mag für Projekte ausreichen, bei denen jeder eine grobe Ahnung davon hat, wer wofür zuständig ist. Hingegen wird diese Vorgehensweise scheitern, wenn eine große Entwicklergruppe an allen möglichen Teilen des Projekts aktiv ist und Konflikte vermieden werden sollen. In solchen Fällen überschneiden sich die Zuständigkeiten, man kann jedoch nichts »den Gang runter brüllen«, da man über die ganze Welt verteilt arbeitet.

Eine »Watch2« genannte CVS-Funktion gibt den Entwicklern ein Mittel in die Hand, um andere darüber zu informieren, wer gerade an welchen Dateien arbeitet. Indem er ein Watch auf eine Datei setzt, kann ein Entwickler CVS veranlassen, ihn zu benachrichtigen, sobald ein anderer beginnt, ebenfalls an ihr zu arbeiten. Diese Benachrichtigungen werden normalerweise als E-Mail versendet, man kann aber auch andere Benachrichtigungsmethoden einrichten.

Um Watches verwenden zu können, muss man ein oder zwei Dateien im Administrationsteil des Archivs anpassen. Weiterhin ist es erforderlich, dass die Entwickler einige Zusatzschritte in den Checkout/Update/Commit-Zyklus einfügen. Die auf Archivseite nötigen Änderungen sind recht einfach: Man muss CVSROOT/notify so abändern, dass CVS weiß, wie Benachrichtigungen durchgeführt werden sollen. Eventuell muss man auch einige Zeilen in CVSROOT/users einfügen, um die externen E-Mail-Adressen festzulegen.

In ihrer Arbeitskopie müssen die Entwickler CVS mitteilen, welche Dateien beobachtet werden sollen, damit CVS ihnen eine Benachrichtigung schicken kann, wenn jemand anders an diesen Dateien zu arbeiten beginnt. Die Entwickler müssen außerdem CVS informieren, wenn sie damit anfangen oder aufhören, an einer Datei zu arbeiten, damit CVS es denjenigen mitteilen kann, die ein Watch gesetzt haben. Folgende Kommandos sind für diese Zusatzschritte zuständig:

cvs watch
cvs edit
cvs unedit
Bemerkung
Das Kommando watch unterscheidet sich von den normalen CVS-Kommandos dadurch, dass es zusätzliche Unterkommandos benötigt, wie etwa cvs watch add..., cvs watch remove..., und so weiter.

Im Folgenden werfen wir einen Blick darauf, wie man Watches im Archiv aktiviert, und darauf, wie Watches aus Entwicklersicht eingesetzt werden. Zwei Beispielnutzer, jrandom und qsmith, haben beide ihre eigene Arbeitskopie desselben Projektes, sie können sogar an verschiedenen Computern arbeiten. Wie üblich wird in allen Beispielen davon ausgegangen, dass die Umgebungsvariable $CVSROOT bereits gesetzt wurde, sodass es bei keinem CVS-Kommando nötig ist, -d <ARCHIV> mit anzugeben.


3.1 Watches im Archiv aktivieren

Zunächst muss CVSROOT/notify angepasst werden, um E-Mail-Benachrichtigungen einzuschalten. Das kann von einem Entwickler erledigt werden, der Administrator muss es nur dann selbst erledigen, wenn kein Entwickler die Berechtigung hat, die Verwaltungsdateien zu verändern. In beiden Fällen ist zuerst der Administrationsbereich auszuchecken und die Datei notify zu editieren:

user@linux ~$ cvs -q co CVSROOT
U CVSROOT/checkoutlist
U CVSROOT/commitinfo
U CVSROOT/config
U CVSROOT/cvswrappers
U CVSROOT/editinfo
U CVSROOT/loginfo
U CVSROOT/modules
U CVSROOT/notify
U CVSROOT/rcsinfo
U CVSROOT/taginfo
U CVSROOT/verifymsg
user@linux ~$ cd CVSROOT
user@linux ~$ emacs notify
user@linux ~$ ...

Falls Sie notify zum ersten Mal öffnen, werden Sie in etwa Folgendes sehen:

Datei notify
# The "notify" file controls where notifications from watches set by
# "cvs watch add" or "cvs edit" are sent. The first entry on a line is
# a regular expression which is tested against the directory that the
# change is being made to, relative to the &#36;CVSROOT. If it matches,
# then the remainder of the line is a filter program that should contain
# one occurrence of %s for the user to notify, and information on its
# standard input.
#
# "ALL" or "DEFAULT" can be used in place of the regular expression.
#
# For example:
# ALL mail %s -s "CVS notification"
      

Es muss lediglich die letzte Zeile einkommentiert werden, indem das führende Doppelkreuz (#) entfernt wird. Obwohl die Datei notify dieselbe flexible Schnittstelle (reguläre Ausdrücke für die Verzeichnisnamen) wie die anderen administrativen Dateien bietet, werden Sie diese Flexibilität hier wohl nie brauchen. Der einzig vorstellbare Grund, mehrere Zeilen mit jeweils einem regulären Ausdruck für einen bestimmten Teil des Archivs haben zu wollen, wäre, wenn Sie unterschiedliche Benachrichtigungsarten für die verschiedenen Projekte haben möchten. Wie auch immer, eine normale E-Mail ist ein völlig ausreichender Benachrichtigungsmechanismus, er wird für die meisten Projekte verwendet.

Um die E-Mail-Benachrichtigung einzuschalten, wird die Zeile

ALL mail %s -s "CVS notification"

wohl auf jedem normalen UNIX-Rechner funktionieren. Die Anweisung bewirkt, dass Benachrichtigungen als E-Mail versendet werden, mit »CVS notification« als Betreff, wobei der Ausdruck ALL wie üblich für alle Verzeichnisse steht. Wenn Sie diese Zeile einkommentiert haben, sollten Sie die Datei notify durch einen Commit dem Archiv zukommen lassen, damit es die Änderung bemerkt5:

user@linux ~$ cvs ci -m "turned on watch notification"
cvs commit: Examining .
Checking in notify;
/usr/local/newrepos/CVSROOT/notify,v <-- notify
new revision: 1.2; previous revision: 1.1
done
cvs commit: Rebuilding administrative file database
user@linux ~$ floss$

Die Anpassung der Datei notify kann auch schon alles sein, was im Archiv zum Aktivieren der Watches getan werden muss. Wenn jedoch auch Entwickler an anderen Rechnern am Projekt teilnehmen, dann muss wahrscheinlich auch noch die Datei CVSROOT/users angepasst werden. Die Aufgabe der Datei users liegt darin, CVS mitzuteilen, wohin die E-Mail-Benachrichtigungen für diejenigen Benutzer gesendet werden müssen, die keine lokale E-Mail-Adresse haben. Das Format jeder Zeile der Datei users:

CVS_BENUTZERNAME:EMAILADRESSE

Zum Beispiel:
qsmith:quentinsmith@ganzweitweg.com

Der CVS-Benutzername am Anfang der Zeile korrespondiert mit einem CVS-Benutzernamen in CVSROOT/password (falls vorhanden und falls die Zugriffsmethode pserver verwendet wird). Ansonsten ist es der Benutzername auf Serverseite der Person, die CVS verwendet. Dem Doppelpunkt folgt die externe E-Mail-Adresse, an die CVS die Watch-Benachrichtigungen für diesen Benutzer schicken soll.

Unglücklicherweise existiert die Datei users (zum Zeitpunkt des Schreibens) nicht in der CVS-Standarddistribution. Weil es sich um eine administrative Datei handelt, genügt es nicht, sie zu erzeugen, sie mit cvs add dem Archiv hinzuzufügen und einen Commit auszuführen, sondern man muss sie auch noch in die CVSROOT/checkoutlist eintragen, damit immer eine ausgecheckte Kopie im Archiv vorliegt.

Hier eine Beispielssitzung, die diesen Vorgang illustriert:

user@linux ~$ floss$ emacs checkoutlist
... (die Zeile für die Datei users hinzufügen) ...
user@linux ~$ floss$ emacs users
... (die Zeile für qsmith hinzufügen) ...
user@linux ~$ floss$ cvs add users
user@linux ~$ floss$ cvs ci -m "added users to checkoutlist, qsmith to users"
cvs commit: Examining .
Checking in checkoutlist;
/usr/local/newrepos/CVSROOT/checkoutlist,v <-- checkoutlist
new revision: 1.2; previous revision: 1.1
done
Checking in users;
/usr/local/newrepos/CVSROOT/users,v <-- users
new revision: 1.2; previous revision: 1.1
done
cvs commit: Rebuilding administrative file database
user@linux ~$

Es ist durchaus möglich, das erweiterte Format für die E-Mail-Adresse in CVSROOT/users zu verwenden, man muss nur darauf achten, dass alle Leerzeichen durch Anführungszeichen gekapselt werden. Zum Beispiel ist Folgendes möglich:

qsmith:"Quentin Q. Smith <quentinsmith@ganzweitweg.com>"

oder auch:

qsmith:'Quentin Q. Smith <quentinsmith@ganzweitweg.com>'

So geht es allerdings nicht:

qsmith:"Quentin Q. Smith" <quentinsmith@ganzweitweg.com>

Probieren Sie im Zweifelsfall das Kommando, wie es in der Datei notify angegeben ist, manuell aus. Es muss lediglich das %s in

mail %s -s "CVS notification"

durch das, was in der Datei users nach dem Doppelpunkt folgt, ersetzt werden. Wenn es auf der Kommandozeile funktioniert, dann sollte es auch in der Datei users funktionieren.

Die Datei checkout sollte jetzt in etwa so aussehen6:

Datei checkout
# The "checkoutlist" file is used to support additional version controlled
# administrative files in &#36;CVSROOT/CVSROOT, such as template files.
#
# The first entry on a line is a filename which will be checked out from
# the corresponding RCS file in the &#36;CVSROOT/CVSROOT directory.
# The remainder of the line is an error message to use if the file cannot
# be checked out.
#
# File format:
#
# [&lt;whitespace>]&lt;filename&gt;&lt;whitespace&gt;&lt;error message&gt;&lt;end-of-line&gt;
#
# comment lines begin with '#'
users Unable to check out 'users' file in CVSROOT.
      

Und die Datei users sieht in etwa so aus:

Datei users
qsmith:quentinsmith@ganzweitweg.com
      

Das Archiv ist nun für Watches vorbereitet. Werfen wir einen Blick darauf, was die Entwickler an ihren Arbeitskopien machen müssen.

Watches bei der Entwicklung verwenden

Zuerst wird ein Entwickler eine Arbeitskopie auschecken und sich selbst auf die Liste der Beobachter (»Watch List«) einer Datei des Projekts setzen:

user@linux ~$ whoami
jrandom
user@linux ~$ cvs -q co myproj
U myproj/README.txt
U myproj/foo.gif
U myproj/hello.c
U myproj/a-subdir/whatever.c
U myproj/a-subdir/subsubdir/fish.c
U myproj/b-subdir/random.c
user@linux ~$ cd myproj
user@linux myproj$ cvs watch add hello.c
user@linux myproj$

Das letzte Kommando, cvs watch add hello.c, teilt CVS mit, dass jrandom benachrichtigt werden soll, wenn jemand beginnt, an hello.c zu arbeiten. Der Benutzer jrandom wird also der Liste der Beobachter hinzugefügt. Damit CVS Benachrichtigungen versenden kann, sobald eine Datei bearbeitet wird, muss der sie bearbeitende Benutzer das CVS mitteilen, indem er zunächst cvs edit für die Datei aufruft. CVS hat keine andere Möglichkeit, festzustellen, dass jemand eine Datei zu bearbeiten beginnt. Sobald der Checkout durchgeführt wurde, ist CVS normalerweise bis zum nächsten Update oder Commit nicht mehr beteiligt. Letzteres geschieht aber erst, nachdem die Datei schon bearbeitet wurde:

user@linux ~$ whoami
qsmith
user@linux ~$ cvs -q co myproj
U myproj/README.txt
U myproj/foo.gif
U myproj/hello.c
U myproj/a-subdir/whatever.c
U myproj/a-subdir/subsubdir/fish.c
U myproj/b-subdir/random.c
user@linux ~$ paste$ cd myproj
user@linux ~$ paste$ cvs edit hello.c
user@linux ~$ paste$ emacs hello.c
...

Wenn qsmith cvs edit hello.c aufruft, schaut sich CVS die Watch-Liste für hello.c an, sieht, dass jrandom darauf vertreten ist, und schickt jrandom eine E-Mail, die ihm sagt, dass qsmith damit begonnen hat, die Datei zu bearbeiten. Die E-Mail hat sogar den Anschein, als käme sie von qsmith:

Email an jrandom
From: qsmith
Subject: CVS notification
To: jrandom
Date: Sat, 17 Jul 1999 22:14:43 -0500
myproj hello.c
--
Triggered edit watch on /usr/local/newrepos/myproj
By qsmith
      

Außerdem wird jrandom jedes Mal, wenn qsmith (oder sonst jemand) den Commit einer neuen Revision von hello.c ausführt, eine weitere E-Mail erhalten:

Email commit
myproj hello.c
--
Triggered commit watch on /usr/local/newrepos/myproj
By qsmith
      

Nach Erhalt dieser E-Mails wird sich jrandom sofort ein Update von hello.c holen wollen, damit sie sehen kann, was qsmith geändert hat; möglicherweise wird sie qsmith eine E-Mail schreiben, um herauszufinden, warum er an der Datei Änderungen vorgenommen hat. Es bleibt zu beachten, dass niemand qsmith gezwungen hat, cvs edit auszuführen, vermutlich wollte er also, dass jrandom erfährt, was er vorhatte. Andererseits: Selbst wenn er cvs edit vergessen hätte, würde sein Commit dennoch das Verschicken von Benachrichtigungen auslösen. Der Sinn, cvs edit zu benutzen, liegt darin, dass Beobachtende benachrichtigt werden, bevor man die Arbeit an einer Datei aufnimmt. Die Beobachtenden können einen dann informieren, wenn sie einen Konflikt kommen sehen.

CVS geht davon aus, dass jeder, der cvs edit auf eine Datei anwendet, selbst - zumindest temporär - auf die Liste der Beobachter der Datei gesetzt werden will, für den Fall, dass jemand anders beginnt, Änderungen vorzunehmen. Als qsmith cvs edit aufgerufen hat, ist er ein Beobachter von hello.c geworden. Sowohl er als auch jrandom wären benachrichtigt worden, hätte ein Dritter cvs edit auf die Datei angewendet oder den Commit einer neuen Revision vorgenommen.

Allerdings glaubt CVS, dass Personen, die eine Datei bearbeiten, nur so lange auf der Beobachtungsliste sein möchten, wie sie daran arbeiten. Benutzer dieser Art werden automatisch von der Beobachtungsliste genommen, wenn sie mit ihren Änderungen fertig sind. Sollten sie es wünschen, dauerhafte Beobachter der Datei zu werden, müssten sie cvs add watch aufrufen. CVS unterstellt, dass jemand mit seiner Arbeit an einer Datei fertig ist, sobald er den Commit der Datei ausgeführt hat - jedenfalls bis zum nächsten Mal.

Jeder, der auf die Beobachtungsliste einer Datei nur dadurch gelangt, dass er cvs edit aufruft, wird als temporärer Beobachter geführt und automatisch von der Beobachtungsliste genommen, sobald er die Änderungen an der Datei per Commit abgeschlossen hat. Wenn er danach wieder etwas bearbeiten möchte, muss er cvs edit noch einmal aufrufen.

Die Annahme, dass der erstbeste Commit die Arbeitssitzung an der Datei beendet, ist natürlich nur eine Vermutung, denn CVS kann ja nicht wissen, wie viele Commits jemand benötigt, um seine Änderungen abzuschließen. Die Vermutung trifft am wahrscheinlichsten bei so genannten »One-off7«-Korrekturen zu, Änderungen, bei denen jemand nur schnell eine Kleinigkeit korrigieren möchte und den Commit gleich durchführt. Für längere Arbeitssitzungen an einer Datei, die mehrere Commits umfassen, sollten die Benutzer sich dauerhaft auf die Beobachtungsliste der Datei setzen:

user@linux ~$ cvs watch add hello.c
user@linux ~$ cvs edit hello.c
user@linux ~$ paste$ emacs hello.c
...
user@linux ~$ paste$ cvs commit -m "print hello in Sanskrit"

Nun bleibt qsmith auch nach einem Commit auf der Beobachtungsliste von hello.c, da er watch add ausgeführt hat. Übrigens wird qsmith keine Benachrichtigung seiner eigenen Änderungen erhalten, die bekommen nur andere Beobachter. CVS ist klug genug, einen nicht über eigene Änderungen zu informieren.

Eine Bearbeitungssitzung abschließen

Wenn Sie kein Commit durchführen wollen, die Bearbeitungssitzung aber explizit beenden wollen, können Sie das mit cvs unedit tun:

user@linux ~$ cvs unedit hello.c

Doch Vorsicht! Dadurch wird nicht nur allen Beobachtenden gemeldet, dass man mit dem Bearbeiten fertig ist, zusätzlich wird Ihnen noch angeboten, alle Änderungen an der Datei, die Sie noch nicht durch einen Commit bestätigt haben, rückgängig zu machen:

user@linux ~$ paste$ cvs unedit hello.c
hello.c has been modified; revert changes? y
user@linux ~$

Wenn Sie hier mit »y« (für »yes«) antworten, wird CVS all Ihre Änderungen rückgängig machen und allen Beobachtenden mitteilen, dass Sie die Datei nicht mehr bearbeiten. Wenn Sie mit »n« (»no«) antworten, behält CVS Ihre Änderungen bei und vermerkt Sie weiterhin als Bearbeiter der Datei. (Es wird also keine Mitteilung verschickt - alles verhält sich so, als hätten Sie cvs unedit nie aufgerufen.) Es mag ein wenig besorgniserregend erscheinen, dass CVS anbietet, mit einem einzigen Tastendruck alle Änderungen zu verwerfen; die Logik dahinter ist allerdings einleuchtend: Wenn Sie »der Welt« mitteilen, dass Sie eine Bearbeitungssitzung abschließen, dann sind die Änderungen, die Sie noch nicht mit einem Commit bestätigt haben, vermutlich solche, die Sie gar nicht beibehalten wollen. CVS sieht es jedenfalls so. Seien Sie also vorsichtig.

Kontrolle über die zu beobachtenden Aktionen

Beobachter werden normalerweise über drei Aktionsarten informiert: das Bearbeiten einer Datei (edits), den Commit und das Ende der Arbeiten an einer Datei (unedits). Falls Sie jedoch beispielsweise nur über Commits benachrichtigt werden wollen, können Sie die Benachrichtigungen auch mit der -a-Option einschränken (a für Aktion):

user@linux ~$ cvs watch add -a commit hello.c

Wenn Sie jedoch sowohl das Editieren als auch den Commit einer Datei beobachten wollen, können Sie die -a-Option auch zwei Mal angeben:

user@linux ~$ cvs watch add -a edit -a commit hello.c

Wenn Sie eine Watch zusammen mit der -a-Option setzen, werden schon existierende Watches dadurch nicht entfernt. Wenn Sie schon alle drei Aktionen auf hello.c beobachten, hat der Aufruf

user@linux ~$ cvs watch add -a commit hello.c

keinen Effekt - Sie sind weiterhin Beobachter aller drei Aktionen. Um Watches zu entfernen, sollten Sie

user@linux ~$ cvs watch remove hello.c

aufrufen, was, wie add, normalerweise alle drei Aktionen von der Beobachtung ausschließt. Falls Sie -a-Argumente übergeben, werden nur die Watches entfernt, die Sie angeben:

user@linux ~$ floss$ cvs watch remove -a commit hello.c

Das bedeutet, dass Sie keine weitere Benachrichtigung über ein Commit bekommen möchten, aber weiterhin über Beginn und Ende des Editierens informiert werden möchten - vorausgesetzt, Sie beobachteten diese schon vorher.

Es gibt zwei spezielle Aktionen, die Sie zusammen mit der -a-Option übergeben können: all für alle oder none für keine. Da es das vorgegebene Verhalten von CVS ist, wenn -a nicht mit angegeben wird, alle Aktionen zu beobachten, und da none, also keine Aktionen zu beobachten, dasselbe ist, wie sich ganz von der Beobachtungsliste herunterzunehmen, ist eine Situation, in der Sie eine dieser Sonderoptionen mit angeben wollen, nur schwer vorzustellen. Andererseits ist die -a-Option auch für edit verwendbar, und in diesem Fall kann es von Nutzen sein, all oder none anzugeben. Zum Beispiel könnte jemand, der nur sehr kurz an einer Datei arbeitet, keine Benachrichtigungen darüber wünschen, was andere an der Datei ändern. So bewirkt das Kommando

user@linux ~$ whoami
qsmith
user@linux ~$ cvs edit -a none README.txt

dass die Beobachter der Datei README.txt darüber benachrichtigt werden, dass qsmith drauf und dran ist, sie zu bearbeiten, qsmith selbst würde aber nicht als kurzzeitiger Beobachter geführt werden (was normalerweise der Fall wäre), da er darum gebeten hat, keine Aktionen zu beobachten.

Beachten Sie, dass Sie nur die eigenen Beobachtungen mit dem cvs watch-Kommando beeinflussen können. Sie können aufhören, eine Datei zu beobachten, aber Sie können fremde Watches nicht ändern.

Wie man herausfindet, wer was beobachtet

Manchmal kann es nützlich sein, zu überprüfen, wer eine Datei beobachtet, bevor man cvs edit aufruft, oder man möchte einfach sehen, wer was unter Beobachung hat, ohne sich selbst auf eine Beobachtungsliste zu setzen. Oder man hat einfach vergessen, wie denn der eigene Status nun genau ist. Wenn man einige Watches gesetzt und wieder zurückgesetzt hat und einige Dateien per Commit zurückgegeben hat, kann man sehr leicht den Überblick darüber verlieren, was man beobachtet und bearbeitet.

CVS bietet zwei Kommandos, mit denen man anzeigen kann, wer Dateien beobachtet und wer Dateien unter Bearbeitung hat: cvs watchers und cvs editors.

user@linux ~$ whoami
jrandom
user@linux ~$ cvs watch add hello.c
user@linux ~$ cvs watchers hello.c
hello.c jrandom edit unedit commit
user@linux ~$ cvs watch remove -a unedit hello.c
user@linux ~$ cvs watchers hello.c
hello.c jrandom edit commit
user@linux ~$ cvs watch add README.txt
user@linux ~$ cvs watchers
README.txt jrandom edit unedit commit
hello.c jrandom edit commit
user@linux ~$

Beachten Sie, dass beim letzten cvs watchers-Kommando keine Dateien angegeben sind. Darum werden die Beobachter aller Dateien angezeigt - und natürlich nur die Dateien, die Beobachter haben.

Dieses Verhalten haben die watch- und edit-Kommandos mit anderen CVS-Kommandos gemeinsam. Wenn Dateinamen mit angegeben werden, wirken sie sich auf diese Dateien aus. Geben Sie Verzeichnisnamen an, sind alle Dateien in den Verzeichnissen und in den darin liegenden Unterverzeichnissen gemeint. Wird gar nichts spezifiziert, arbeiten die Kommandos auf dem aktuellen Verzeichnis und auf allem darunter, auf allen darunter liegenden Ebenen. Zum Beispiel (als Fortsetzung derselben Sitzung):

user@linux ~$ cvs watch add a-subdir/whatever.c
user@linux ~$ cvs watchers
README.txt jrandom edit unedit commit
hello.c jrandom edit commit
a-subdir/whatever.c jrandom edit unedit commit
user@linux ~$ cvs watch add
user@linux ~$ cvs watchers
README.txt jrandom edit unedit commit
foo.gif jrandom edit unedit commit
hello.c jrandom edit commit unedit
a-subdir/whatever.c jrandom edit unedit commit
a-subdir/subsubdir/fish.c jrandom edit unedit commit
b-subdir/random.c jrandom edit unedit commit
user@linux ~$

Durch die letzten beiden Kommandos wurde jrandom Beobachterin aller Dateien des Projekts und hat dann die Beobachtungsliste für alle Dateien im Projekt abgerufen. Die Ausgabe von cvs watchers passt nicht immer exakt in die Spalten, da CVS Tabulatoren mit Informationen variabler Länge vermischt, doch das Format ist einheitlich:

[DATEINAME] [leerzeichen] BEOBACHTER [leerzeichen] BEOBACHTETE_AKTION ...

Folgendes passiert, wenn qsmith eine dieser Dateien editiert:

user@linux ~$ cvs edit hello.c
user@linux ~$ cvs watchers
README.txt jrandom edit unedit commit
foo.gif jrandom edit unedit commit
hello.c jrandom edit commit unedit
qsmith tedit tunedit tcommit
a-subdir/whatever.c jrandom edit unedit commit
a-subdir/subsubdir/fish.c jrandom edit unedit commit
b-subdir/random.c jrandom edit unedit commit

Bei der Datei hello.c ist ein weiterer Beobachter hinzugekommen: qsmith selbst. Beachten Sie, dass der Dateiname am Anfang der Zeile nicht wiederholt wird, sondern durch Leerzeichen ersetzt wird - falls Sie jemals ein Programm schreiben, das die Ausgabe von watchers einliest, kann das wichtig sein. Da er hello.c bearbeitet, ist qsmith temporärer Beobachter der Datei - so lange, bis er eine neue Revision von hello.c per Commit erzeugt. Das t vor jeder der Aktionen zeigt an, dass es sich nur um temporäre Watches handelt. Wenn sich qsmith nun als normaler Beobachter von hello.c hinzufügt:

user@linux ~$ paste$ cvs watch add hello.c
README.txt jrandom edit unedit commit
foo.gif jrandom edit unedit commit
hello.c jrandom edit commit unedit
qsmith tedit tunedit tcommit edit unedit commit
a-subdir/whatever.c jrandom edit unedit commit
a-subdir/subsubdir/fish.c jrandom edit unedit commit
b-subdir/random.c jrandom edit unedit commit

dann wird er sowohl als temporärer als auch als permanenter Beobachter aufgelistet. Man könnte erwarten, dass der permanente Status den temporären einfach überschreibt, sodass die Zeile folgendermaßen aussähe:

qsmith edit unedit commit

CVS kann aber nicht einfach den temporären Status ersetzen, da es nicht weiß, in welcher Reihenfolge die Aktionen ablaufen: Wird qsmith sich von der permanenten Beobachtungsliste entfernen, bevor er die Bearbeitungssitzung beendet, oder wird er die Änderungen abschließen und trotzdem Beobachter bleiben? Im ersten Fall würden die edit/unedit/commit-Aktionen verschwinden, die tedit/tunedit/tcommit würden aber bleiben. Im zweiten Fall wäre es umgekehrt.

Wie auch immer - dieser Aspekt der Beobachtungslisten ist normalerweise nicht von großem Interesse. Es genügt,

user@linux ~$ floss$ cvs watchers

oder

user@linux ~$ floss$ cvs editors

von der obersten Verzeichnisebene des Projekts aus aufzurufen, um zu sehen, wer was tut. Man braucht nicht zu wissen, wen welche Aktionen kümmern, wichtig sind die Namen der Personen und der Dateien.

Benutzer an Watches erinnern

Sie haben es wahrscheinlich schon bemerkt: Die Beobachtungs-Features sind völlig von der Kooperation aller Entwickler abhängig. Wenn jemand einfach eine Datei ändert, ohne zuvor cvs edit aufzurufen, wird es niemand mitbekommen, bis die Änderungen mit Commit beendet werden. Da cvs edit einen zusätzlichen, nicht routinemäßigen Schritt darstellt, wird er leicht vergessen.

Obwohl CVS niemanden zwingen kann, cvs edit zu verwenden, hat es dennoch einen Mechanismus, um die Leute wenigstens daran zu erinnern: das Kommando watch on:

user@linux ~$ cvs -q co myproj
U myproj/README.txt
U myproj/foo.gif
U myproj/hello.c
U myproj/a-subdir/whatever.c
U myproj/a-subdir/subsubdir/fish.c
U myproj/b-subdir/random.c
user@linux ~$ cd myproj
user@linux ~$ cvs watch on hello.c
user@linux ~$

Durch den Aufruf von cvs watch on hello.c bewirkt jrandom, dass zukünftige Checkouts von myproj die Datei hello.c in der Arbeitskopie mit dem Nur-lese-Status erzeugen. Versucht nun qsmith, daran zu arbeiten, wird er feststellen, dass die Datei nur lesbar ist, und wird so daran erinnert, zuerst cvs edit aufzurufen:

user@linux ~$ cvs -q co myproj
U myproj/README.txt
U myproj/foo.gif
U myproj/hello.c
U myproj/a-subdir/whatever.c
U myproj/a-subdir/subsubdir/fish.c
U myproj/b-subdir/random.c
user@linux ~$ cd myproj
user@linux ~$ ls -l
total 6
drwxr-xr-x 2 qsmith users 1024 Jul 19 01:06 CVS/
-rw-r--r-- 1 qsmith users 38 Jul 12 11:28 README.txt
drwxr-xr-x 4 qsmith users 1024 Jul 19 01:06 a-subdir/
drwxr-xr-x 3 qsmith users 1024 Jul 19 01:06 b-subdir/
-rw-r--r-- 1 qsmith users 673 Jun 20 22:47 foo.gif
-r--r--r-- 1 qsmith users 188 Jul 18 01:20 hello.c
user@linux ~$

Sobald er das getan hat, wird die Datei auch beschreibbar werden; er kann sie nun editieren. Wenn er die Änderungen mittels Commit abschickt, wird sie wieder nur lesbar:

user@linux ~$ cvs edit hello.c
user@linux ~$ ls -l hello.c
-rw-r--r-- 1 qsmith users 188 Jul 18 01:20 hello.c
emacs hello.c
...
user@linux ~$ cvs commit -m "say hello in Aramaic" hello.c
Checking in hello.c;
/usr/local/newrepos/myproj/hello.c,v <-- hello.c
new revision: 1.12; previous revision: 1.11
done
user@linux ~$ ls -l hello.c
-r--r--r-- 1 qsmith users 210 Jul 19 01:12 hello.c
user@linux ~$

Sein edit und sein commit wird Benachrichtigungen an alle Beobachter der Datei hello.c versenden. Beachten Sie, dass jrandom nicht notwendigerweise selbst Beobachter der Datei ist. Durch den Aufruf von cvs watch on hello.c hat sich jrandom nicht selbst auf die Beobachtungsliste gesetzt, sie hat nur erwirkt, dass hello.c beim Checkout den Nur-lese-Status erhält. Jeder, der eine Datei beobachten will, muss selbst daran denken, sich auf die Beobachtungsliste zu setzen, dabei kann ihm CVS nicht helfen.

Es mag eher die Ausnahme sein, die Beobachtung einer einzelnen Datei einzuschalten. Normalerweise werden Watches für das gesamte Projekt eingeschaltet:

user@linux ~$ cvs -q co myproj
U myproj/README.txt
U myproj/foo.gif
U myproj/hello.c
U myproj/a-subdir/whatever.c
U myproj/a-subdir/subsubdir/fish.c
U myproj/b-subdir/random.c
user@linux ~$ cd myproj
user@linux ~$ cvs watch on
user@linux ~$

Diese Aktion kommt der Ankündigung einer Grundsatzentscheidung für das gesamte Projekt gleich: »Bitte verwenden Sie cvs edit, um Beobachtern mitzuteilen, woran Sie gerade arbeiten, und beobachten Sie ruhig jede Datei, die Sie interessiert oder für die Sie sich verantwortlich fühlen.« Jede Datei des Projekts erhält nun beim Checkout den Nur-lese-Status, auf dass sich die Leute daran erinnern mögen, dass sie cvs edit aufzurufen haben, bevor sie irgendwelche Arbeiten daran durchführen.

Obwohl beobachtete Dateien beim Checkout wieder nur lesbar werden, geschieht dies durch Updates seltsamerweise nicht. Hätte qsmith den Checkout seiner Arbeitskopie ausgeführt, bevor jrandom cvs watch on aufgerufen hat, blieben seine Dateien schreibbar, selbst nach einem Update. Jedoch werden alle Dateien, die er mit einem Commit dem Archiv zukommen lässt, nachdem jrandrom die Watches eingeschaltet hat, nur lesbar. Schaltet jrandom die Watches ab

user@linux ~$ floss$ cvs watch off

werden qsmiths Dateien nicht von Geisterhand wieder beschreibbar. Andererseits werden sie auch nicht nach seinen Commits wieder nur lesbar, was der Fall wäre, wären die Watches noch eingeschaltet.

Es bleibt zu beachten, dass qsmith, wenn er richtig hinterhältig wäre, die Dateien seiner Arbeitskopie auch mit dem normalen Unix-Kommando chmod beschreibbar machen und so cvs edit völlig umgehen könnte:

user@linux ~$ chmod u+w hello.c

oder, wenn er alles auf einen Schlag erledigen wollte:

user@linux ~$ paste$ chmod -R u+w .

CVS kann nichts dagegen tun. Die Arbeitskopien sind - bedingt durch ihre Natur - private »Sandkästen", durch die Beobachtungs-Features kann man sie ein klein wenig unter öffentliche Beobachtung stellen, jedoch nur so weit, wie es der Entwickler erlaubt. Nur wenn ein Entwickler etwas ausführt, das das Archiv berührt, wie zum Beispiel ein Commit, gibt er seine Privatsphäre ohne Wenn und Aber auf.

Das Verhältnis zwischen watch add, watch remove, watch on und watch off mag leicht verwirrend erscheinen. Vielleicht hilft es, die Systematik noch einmal zusammenzufassen: add und remove sind dafür da, um Benutzer auf die Beobachtungsliste einer Datei zu setzen oder sie davon zu entfernen; sie haben nichts damit zu tun, ob Dateien beim Checkout das Nur-lese-Attribut erhalten oder ob sie nach einem Commit (wieder) nur lesbar werden. Bei on und off geht es nur um Dateirechte. Sie haben nichts damit zu tun, wer auf einer Beobachtungsliste ist, es geht lediglich darum, die Entwickler daran zu erinnern, sich an die Beobachtungsübereinkunft zu halten, indem die Dateien der Arbeitskopie zunächst nur die Leseberechtigung erhalten.

Vielleicht wirkt das Ganze ja auch ein wenig inkonsistent. Schließlich laufen Watches dem Grundkonzept von CVS entgegen. Es ist eine Teilabkehr von dem idealisierten Universum, in dem viele Entwickler völlig frei an ihren Arbeitskopien arbeiten, unbemerkt von den anderen, bis sie sich entschließen, etwas per Commit zu veröffentlichen. Mit Watches gibt CVS den Entwicklern eine bequeme Methode, die anderen darüber, was in der eigenen Arbeitskopie vor sich geht, zu informieren; allerdings ohne die Möglichkeit, das für die Arbeit mit Watches richtige Verhalten zu erzwingen. Auch gibt es kein festgelegtes Konzept davon, woraus denn eine Arbeitssitzung nun genau besteht. Nichtsdestotrotz können Watches unter gewissen Umständen nützlich sein, wenn die Entwickler sie verwenden.

Wie Watches im Archiv aussehen

Damit mal wieder ein unnötiges Mysterium ausgerottet wird, werfen wir einen kurzen Blick darauf, wie Watches im Archiv implementiert sind. Nur einen ganz kurzen Blick, denn es ist wirklich kein schöner Anblick:

Wenn man ein Watch setzt

user@linux ~$ pwd
/home/jrandom/myproj
user@linux ~$ cvs watch add hello.c
user@linux ~$ cvs watchers
hello.c jrandom edit unedit commit
user@linux ~$

hält CVS das in einer gesonderten Datei, CVS/fileattr, im zuständigen Unterverzeichnis des Archivs fest:

user@linux ~$ cd /usr/local/newrepos
user@linux ~$ ls
CVSROOT/ myproj/
user@linux ~$ cd myproj
user@linux ~$ ls
CVS/ a-subdir/ foo.gif,v
README.txt,v b-subdir/ hello.c,v
user@linux ~$ cd CVS
user@linux ~$ ls
fileattr
user@linux ~$ cat fileattr
Fhello.c _watchers=jrandom>edit+unedit+commit
user@linux ~$

Die Tatsache, dass fileattr in einem Unterverzeichnis des Archivs mit Namen CVS abgelegt wird, heißt jetzt aber nicht, dass das Archiv zu einer Arbeitskopie geworden ist. Es ist einfach so, dass der Name CVS schon für die Buchführung in der Arbeitskopie reserviert ist und sich CVS deshalb sicher sein kann, dass es niemals ein Unterverzeichnis mit diesem Namen im Archiv speichern muss.

Ich werde das Dateiformat von fileattr hier nicht formal beschreiben, man kapiert es recht schnell, wenn man zusieht, wie sich die Datei von Kommando zu Kommando verändert:

user@linux ~$ cvs watch add hello.c
user@linux ~$ cat /usr/local/newrepos/myproj/CVS/fileattr
Fhello.c _watchers=jrandom>edit+unedit+commit
user@linux ~$ cvs watch add README.txt
user@linux ~$ cat /usr/local/newrepos/myproj/CVS/fileattr
Fhello.c _watchers=jrandom>edit+unedit+commit
FREADME.txt _watchers=jrandom>edit+unedit+commit
user@linux ~$ cvs watch on hello.c
user@linux ~$ cat /usr/local/newrepos/myproj/CVS/fileattr
Fhello.c _watchers=jrandom>edit+unedit+commit;_watched=
FREADME.txt _watchers=jrandom>edit+unedit+commit
user@linux ~$ cvs watch remove hello.c
user@linux ~$ cat /usr/local/newrepos/myproj/CVS/fileattr
Fhello.c _watched=
FREADME.txt _watchers=jrandom>edit+unedit+commit
user@linux ~$ cvs watch off hello.c
user@linux ~$ cat /usr/local/newrepos/myproj/CVS/fileattr
FREADME.txt _watchers=jrandom>edit+unedit+commit
user@linux ~$

Die Informationen über Bearbeitungssitzungen werden ebenfalls in fileattr abgelegt. Folgendes geschieht, wenn qsmith sich als Bearbeiter einträgt:

user@linux ~$ cvs edit hello.c
user@linux ~$ cat /usr/local/newrepos/myproj/CVS/fileattr
Fhello.c _watched=;_editors=qsmith>Tue Jul 20 04:53:23 1999 GMT+floss\
+/home/qsmith/myproj;_watchers=qsmith>tedit+tunedit+tcommit
FREADME.txt _watchers=jrandom>edit+unedit+commit

Letztlich bleibt zu bemerken, dass CVS die Datei fileattr sowie das Unterverzeichnis CVS löscht, wenn für keine der Dateien in einem Verzeichnis noch Beobachter oder Bearbeiter vorhanden sind:

user@linux ~$ cvs unedit
user@linux ~$ cvs watch off
user@linux ~$ cvs watch remove
user@linux ~$ cat /usr/local/newrepos/myproj/CVS/fileattr
cat: /usr/local/newrepos/myproj/CVS/fileattr: No such file or directory

Nach dieser kurzen Enthüllung sollte klar sein, dass man die Analyse des fileattr-Formats besser CVS überlässt. Die Hauptmotivation dafür, eine grobe Ahnung von diesem Format zu haben (von der tiefen Befriedigung zu wissen, was hinter den Vorhängen vor sich geht, einmal abgesehen), liegt darin, dass man möglicherweise eine Erweiterung an der Funktionalität der Watches plant oder dass man eventuell auftretende Probleme beheben kann. Ansonsten ist es ausreichend, zu wissen, dass es keinen Grund zur Beunruhigung gibt, wenn plötzlich ein Unterverzeichnis namens CVS in Ihrem Archiv auftaucht. Es handelt sich einfach um den einzig sicheren Ort, an dem CVS Metainformationen wie eben die Beobachtungslisten speichern kann.




zurück   Seitenanfang Startseite Kapitelanfang Inhaltsverzeichnis GPL   weiter