3.1 Alltägliche Probleme und ihre Lösung

Die folgenden Situationen habe ich erlebt, als ich anderen bei ihren Abenteuern mit CVS zur Seite gestanden habe. Dazu kommen noch einige Punkte, die keine echten Probleme sind, sondern lediglich Fragen, die mir schon einmal gestellt wurden und die ich hier beantworten möchte. Ich halte diese Liste für ziemlich umfassend, und manches, was Sie schon in früheren Kapiteln gelesen haben, kann sich hier wiederholen.

Die Situationen sind entsprechend der Häufigkeit ihres Auftretens angeordnet, die häufigsten dabei zuerst.

Ich bekomme dauernd die Meldung 'Waiting for Locks'. Was soll das?

Wenn Sie eine Meldung wie

erhalten, dann bedeutet das, dass Sie versuchen, auf ein Unterverzeichnis im Archiv zuzugreifen, das momentan von irgendeinem anderen CVS-Prozess belegt wird. Da ein Prozeß in diesem Verzeichnis abläuft, befindet es sich möglicherweise nicht in einem Zustand, der es erlaubt, dass andere CVS-Prozesse darauf zugreifen.

Wenn allerdings diese Wartemeldung lange Zeit bestehen bleibt, dann heißt das, dass ein CVS-Prozess - aus welchem Grund auch immer - dabei gescheitert ist, textblocker sich aufzuräumen. So etwas kann auftreten, wenn CVS plötzlich und unerwartet stirbt, beispielsweise durch Stromausfall bei dem Rechner, der das Archiv beherbergt.

Die Lösung liegt darin, die Lock-Dateien von Hand aus dem fraglichen Verzeichnis im Archiv zu entfernen. Wechseln Sie in das entsprechende Verzeichnis im Archiv, und suchen Sie nach Dateien namens #cvs.lock oder solchen, die mit #cvs.wfl oder #cvs.rfl beginnen. Vergleichen Sie die Zeitstempel der Dateien mit den Startzeiten aller gerade laufenden CVS-Prozesse. Wenn ausgeschlossen ist, dass die Dateien von einem noch laufenden Prozess angelegt worden sind, dann ist es ungefährlich, sie zu löschen. Der wartende CVS-Prozess wird irgendwann merken, dass die Lock-Dateien verschwunden sind - das sollte ungefähr 30 Sekunden dauern -, und wird dann der angeforderten Operation gestatten, fortzufahren.

Wenn Sie an mehr Details interessiert sind, dann lesen Sie unter Locks im Cederqvist nach.

CVS behauptet, dass bei einer Datei der »Up-to-Date Check« fehlschlägt.

Was mache ich bloß?

Keine Panik - das bedeutet einfach, dass sich die Datei, seit Sie sie das letzte Mal ausgecheckt oder ein Update gemacht haben, geändert hat.

Starten Sie cvs update auf der Datei, um die Änderungen aus dem Archiv einzuarbeiten. Wenn die Änderungen mit Ihren lokalen Änderungen kollidieren, dann editieren Sie die Datei, um den Konflikt zu beheben. Versuchen Sie danach erneut den commit - er wird nicht fehlschlagen -, wenn man einmal die Möglichkeit ausschließt, dass jemand eine weitere Revision per Commit veröffentlicht hat, während Sie damit beschäftigt waren, die letzten Änderungen einzuarbeiten.

Ich schaffe es nicht, die pserver-Zugangsmethode ans Laufen zu kriegen.

Der häufigste, aber am wenigsten offensichtliche Grund für dieses Problem ist, dass Sie vergessen haben, das Archiv mit der Option --allow-root in Ihrer inetd-Konfigurationsdatei aufzulisten.

Erinnern Sie sich an die Beispiel-/etc/inetd.conf-Datei aus  Kapitel 4:

       
cvspserver stream tcp nowait root /usr/local/bin/cvs cvs \
--allow-root=/usr/local/newrepos pserver
     
     

(In der eigentlichen Datei ist das eine einzige lange Zeile, ohne den Backslash.)

Der Teil --allow-root=/usr/local/newrepos ist eine Sicherheitsmaßnahme, die dafür sorgt, dass niemand CVS dazu missbraucht, um pserver-Zugang zu Archiven zu erhalten, auf die nur lokal zugegriffen werden soll. Jedes Archiv, auf das pserver-Zugriff möglich sein soll, benötigt einen --allow-root-Eintrag. Sie können so viele --allow-root-Optionen, wie Sie für alle Archive im System benötigen, haben (oder so viele, wie Sie wollen, solange Sie nicht an die Längenbeschränkung der Argumente für inetd stoßen).

Lesen Sie in  Kapitel 4 nach, wenn Sie genauere Informationen zur Einrichtung eines Passwort authentisierten Servers wünschen.

Die pserver-Zugriffsmethode funktioniert IMMER noch nicht!

O.K., wenn es nicht an einem fehlenden --allow-root liegt, gibt es noch andere Möglichkeiten:

Der Benutzer hat keinen Eintrag in der Datei CVSROOT/passwd, und die Datei CVSROOT/config enthält SystemAuth=no, sodass CVS nicht auf die System-passwd-Datei zurückfällt (oder sie enthält SystemAuth=yes, aber die System-passwd-Datei enthält auch keinen Eintrag für diesen Benutzer).

Der Benutzer hat zwar einen Eintrag in CVSROOT/passwd, aber es gibt keinen entsprechenden Benutzer im System, und CVSROOT/passwd bildet den Benutzer nicht auf einen im System gültigen Benutzernamen ab.

Das Passwort ist falsch. (CVS ist aber gut darin, den Benutzer darauf hinzuweisen, also ist das wahrscheinlich nicht die richtige Antwort.)

Die Passwortdateien und /etc/inetd.conf sind richtig eingerichtet, aber Sie haben einen Eintrag wie diesen in /etc/services vergessen:

       
cvspserver 2401/tcp
     
     

und so lauscht inetd gar nicht auf dem Port und kann die Verbindung auch nicht an CVS weiter reichen.

Meine Commits geschehen stückweise, nicht atomar.

Das liegt daran, dass CVS-Commits stückweise geschehen und nicht atomar. :-)

Genauer gesagt laufen sie verzeichnisweise ab. Wenn Sie einen commit (oder ein update oder irgendetwas anderes) ausführen, der mehrere Verzeichnisse betrifft, dann wird CVS jedes korrespondierende Verzeichnis im Archiv nacheinander sperren, während es die Operation darin durchführt.

Bei kleinen bis mittleren Projekten ist das selten ein Problem - CVS erledigt seine Aufgaben in jedem Verzeichnis so schnell, dass es gar nicht auffällt, dass es nicht atomar geschieht. Bei großen Projekten kann es aber leider zu Szenarios wie folgendem kommen. (Stellen Sie sich vor, dass das bei einem Projekt geschieht, das mindestens zwei Unterverzeichnisse (A und B) enthält, die beide viele Dateien enthalten.):

Der Benutzer qsmith startet einen commit, der Dateien aus beiden Unterverzeichnissen betrifft. CVS führt den Commit zuerst mit den Dateien in Verzeichnis B aus (möglicherweise weil qsmith die Verzeichnisse in seiner Kommandozeile in dieser Reihenfolge angegeben hat).

Die Benutzerin jrandom startet cvs update. Aus welchem Grund auch immer startet der Update-Prozess in dem Verzeichnis A in der Arbeitskopie. (CVS gibt keine Garantien, in welcher Reihenfolge es Verzeichnisse oder Dateien bearbeitet, wenn man es nicht dazu zwingt.) Beachten Sie, dass es keinen Konflikt mit den Sperren gibt, da ja qsmith in Verzeichnis A noch gar nicht aktiv ist.

Der commit von qsmith wird mit B fertig und macht bei A weiter und wird auch dort fertig.

Zum Schluss wechselt der update-Prozess von qsmith zu Verzeichnis B und wird auch dort fertig.

Es ist klar, dass, wenn alles vorüber ist, die Arbeitskopie von jrandom die Änderungen von qsmith an Verzeichnis B enthält, nicht jedoch die in Verzeichnis A. Obwohl qsmith vorhatte, dass die Änderungen als Einheit vorgenommen werden, ist es nicht so gekommen. Jetzt ist die Arbeitskopie von jrandom in einem Zustand, den qsmith nie vorhergesehen hätte.

Die Lösung ist natürlich, dass jrandom einen weiteren cvs update-Lauf durchführt, der die noch unberücksichtigten Änderungen aus dem Commit von qsmith nachholt. Das setzt natürlich voraus, dass jrandom überhaupt die Möglichkeit hat, herauszufinden, dass sie nur einen Teil von qsmiths Änderungen mitbekommen hat.

Es gibt für dieses Dilemma keine einfache Lösung. Sie müssen einfach hoffen, dass der inkonsistente Zustand der Arbeitskopie irgendwie auffällt. (Vielleicht lässt sich die Software nicht übersetzen, oder jrandom und qsmith haben eine für beide verwirrende Unterhaltung, bis ihnen auffällt, was passiert sein muss.)

Dass CVS keine atomaren Transaktionen bereitstellt, wird allgemein als Manko gesehen. Der alleinige Grund dafür, dass keine Sperrmechanismen im Hauptverzeichnis des Archivs eingeführt werden, ist der, dass sich dann bei großen Projekten mit vielen Benutzern häufig Verklemmungen dieser Sperren ergeben würden. CVS hat also das kleinere Übel gewählt, das die Häufigkeit dieser Verklemmungen verringert, aber eben diese versetzten Lese- und Schreiboperationen zulässt. Eines Tages wird jemand CVS anpassen (also die Operationen des Archivs beschleunigen), sodass man nicht mehr zwischen zwei Übeln wählen muss; bis dahin müssen wir uns mit den nicht atomaren Vorgängen abfinden.

Für weitere Informationen empfehle ich die Sektion Concurrency im Cederqvist.

Warum verändert CVS dauernd die Zugriffsrechte meiner Dateien?

CVS ist allgemein nicht gut darin, die Zugriffsrechte von Dateien zu bewahren. Wenn man ein Projekt importiert und dann auscheckt, gibt es keine Garantie, dass die Zugriffsrechte der Dateien in der neuen Arbeitskopie dieselben sind wie beim Importieren des Projekts. Wahrscheinlicher ist, dass die Dateien der Arbeitskopie mit denselben Standardzugriffsrechten erzeugt werden, mit denen neue Dateien normalerweise angelegt werden.

Es gibt aber mindestens eine Ausnahme. Wenn Sie ausführbare Shell-Skripten im Projekt speichern wollen, können Sie sie in jeder Arbeitskopie ausführbar machen, indem Sie die korrespondierende Datei im Archiv ausführbar machen:

Beachten Sie, dass, obwohl die Datei ausführbar ist, sie immer noch read-only ist, wie es alle Dateien im Archiv sein sollten. (Wie schon gesagt macht CVS erst eine temporäre Kopie der RCS-Datei, führt alle Operationen auf der Kopie durch und ersetzt, wenn es fertig ist, das Original mit der Kopie.)

Wenn Sie eine ausführbare Datei importieren oder hinzufügen, dann erhält CVS die Executable Flags (diese machen sie ausführbar); wenn also die Rechte von Anfang an richtig gesetzt waren, haben Sie nichts zu befürchten. Wenn Sie allerdings aus Versehen die Datei hinzufügen, bevor Sie sie ausführbar gemacht haben, dann müssen Sie manuell die RCS-Datei im Archiv ausführbar machen.

Bemerkung

Ein Feature namens PreservePermissions wurde CVS hinzugefügt, dass manche dieser Probleme erträglicher machen könnte. Durch dessen Nutzung können aber andere unerwartete Ereignisse auftreten (weshalb ich es hier nicht uneingeschränkt empfehle). Machen Sie sich mit den Punkten config und Special Files im Cederqvist vertraut, bevor Sie PreservePermissions=yes in CVSROOT/config hinein schreiben.

CVS kann unter Windows meine .cvspass-Datei nicht finden. Warum?

Für pserver-Verbindungen sucht CVS auf der Client-Seite in Ihrem Home-Verzeichnis nach der Datei .cvspass. Windows-Maschinen kennen aber kein natürliches Home-Verzeichnis, weswegen CVS in der Umgebungsvariablen %HOME% nachschaut. Man muss aber bei der Einrichtung von HOME sehr vorsichtig sein. Folgendes funktioniert:

       
set HOME=C:
     
     

Das aber nicht:

       
set HOME=C:\
     
     

Der abschließende Backslash reicht aus, um CVS zu verwirren; es wird C:\.cvspass nicht öffnen können.

Die schnelle und dauerhafte Lösung ist also

       
set HOME=C:
     
     

in Ihre autoexec.bat zu schreiben und Windows neu zu starten. Danach sollte CVS-pserver richtig funktionieren.

Meine Arbeitskopie ist auf verschiedene Zweige verteilt. Hilfe!

Sie haben festgestellt, dass verschiedene Unterverzeichnisse Ihrer Arbeitskopie irgendwie in verschiedenen Zweigen gelandet sind? Das liegt vermutlich daran, dass Sie Updates mit der Option -r durchgeführt haben, jedoch nicht vom Hauptverzeichnis Ihrer Arbeitskopie aus.

Kein Problem. Wenn Sie zur Hauptentwicklungslinie zurückkehren wollen, führen Sie einfach

oder

aus dem Hauptverzeichnis aus. Wenn Sie hingegen Ihre ganze Arbeitskopie auf eine bestimmte Entwicklungslinie setzen wollen, führen Sie Folgendes aus:

Es ist an sich nichts Falsches daran, ein oder zwei Unterverzeichnisse Ihrer Arbeitskopie auf einem anderen Zweig zu haben als den Rest, wenn Sie beispielsweise einige kurze Arbeiten in diesem Zweig und nur in diesen bestimmten Verzeichnissen durchführen wollen. Es ist aber generell eine gute Idee zurückzukehren, sobald Sie fertig sind - das Leben ist viel weniger verwirrend, wenn Ihre ganze Arbeitskopie derselben Entwicklungslinie folgt.

Wenn ich export -D durchführe, scheint es manchmal die neusten Änderungen zu missachten!

Das liegt an den unterschiedlich laufenden Uhren auf der lokalen Maschine und im Archiv. Sie können das Problem lösen, indem Sie eine oder beide Uhren neu stellen oder indem Sie ein anderes Datum als Argument zu -D angeben. Es ist durchaus akzeptabel, ein in der Zukunft liegendes Datum (wie zum Beispiel -D tomorrow) anzugeben, wenn das nötig ist, um den Zeitunterschied zu kompensieren.

Ich kann export -r nicht ausführen wegen irgendwelcher 'val-tags'. Was soll das?

Siehe nächste Frage.

Tag-Operationen schlagen wegen irgendwelcher 'val-tags' fehl. Was soll das?

Wenn Sie einen ähnlichen Fehler wie diesen

erhalten, dann bedeutet das, dass der Benutzer, unter dem CVS läuft, nicht die Berechtigung hat, in die Datei CVSROOT/val-tags zu schreiben. In dieser Datei werden gültige Namen von Marken gespeichert, damit CVS schnell feststellen kann, welche Marken gültig sind. Leider verändert CVS diese Datei selbst für Operationen, die auf das Archiv bezogen eigentlich nur lesend sind, wie beispielsweise das Auschecken eines Projektes.

Dieser Fehler in CVS könnte zurzeit, da Sie dies lesen, schon behoben sein. Bis es so weit ist, liegt die Lösung entweder darin, die Datei val-tags world-writeable zu machen oder, wenn das nicht hilft, sie zu löschen oder ihren Eigentümer auf den abzuändern, der CVS laufen lässt. (Man sollte denken, dass das Ändern der Zugriffsrechte genügen sollte, ich habe aber schon mehrere Situationen erlebt, bei denen ich auch den Eigentümer ändern musste.)

Ich habe Probleme mit bindenden Marken, ich möchte sie loswerden.

Verschiedene CVS-Operationen ziehen mit sich, dass die Arbeitskopie eine bindenden Marke, ein so genanntes Sticky Tag, erhält, also eine einzige Marke, der jeder Revision jeder Datei zugeordnet ist. (Im Falle einer verzweigten Version wird die bindende Marke auf jede Datei, die der Arbeitskopie hinzugefügt wird, angewendet.) Ihre Arbeitskopie erhält jedes Mal eine bindende Marke, wenn sie abhängig von einer Marke oder von einem Datum auschecken oder ein Update durchführen.

Zum Beispiel:

oder

Wenn ein Datum oder der Name einer normalen Marke (nicht die eines Zweiges) verwendet wird, dann wird die Arbeitskopie zu einem eingefrorenen Abbild dieses Augenblicks in der Geschichte des Projektes - so werden Sie natürlich nicht in der Lage sein, irgendwelche Änderungen daraus per Commit im Archiv abzulegen.

Um die bindende Marke zu entfernen, lassen Sie update mit der Option -A laufen

wodurch die bindende Marke aufgelöst wird und jede Datei auf den neusten Stand der Hauptentwicklungslinie gebracht wird.

CVS Checkout/Update schlägt mit einer Fehlermeldung fehl, die 'cannot expand modules' lautet.

Das ist ein Fall einer falschen Fehlermeldung in CVS; wahrscheinlich wird früher oder später jemand sie korrigieren, in der Zwischenzeit kann sie Sie aber erwischen.

Die Fehlermeldung sieht etwa so aus:

CVS scheint zu sagen, dass etwas mit der Datei CVSROOT/modules nicht stimmt. In Wahrheit handelt es sich aber um ein Problem mit den Zugriffsrechten im Archiv. Entweder ist das Verzeichnis, das ich auschecken möchte, nicht lesbar, oder eines seiner übergeordneten Verzeichnisse ist nicht lesbar. In diesem Fall war eines der übergeordneten Verzeichnisse schuld:

Lassen Sie sich nicht von dieser offensichtlich falschen Fehlermeldung täuschen - es ist ein Problem mit den Zugriffsrechten im Archiv.

Irgendwie kann ich die Watches nicht abschalten!

Sie haben wahrscheinlich

für alle Dateien aufgerufen, aber vergessen, ebenfalls

aufzurufen. Ein kleiner Hinweis, wie man Probleme mit Watches (Beobachtungslisten) diagnostiziert: Manchmal ist es immens erhellend, wenn man einfach in das Archiv geht und die CVS/fileattr-Dateien direkt untersucht. Siehe  Kapitel 4 für weitere Informationen darüber.

Meine Binärdateien werden verunstaltet.

Haben Sie daran gedacht, -kb anzugeben, als Sie sie dem Archiv hinzugefügt haben? Wenn nicht, dann könnte CVS Zeilenendekonvertierungen oder RCS-Schlüsselwortersetzungen durchgeführt haben. Die einfachste Lösung ist normalerweise, sie als Binärdatei zu kennzeichnen:

und es dann nach Korrektur der Datei dem Archiv per Commit mitzuteilen. CVS wird sie bei dem neuen Commit nicht wieder verändern und bei späteren Commits auch nicht, da es ja jetzt weiß, dass es sich um eine Binärdatei handelt.

CVS macht die Zeilenendekonvertierung nicht richtig.

Wenn Sie CVS auf einer Nicht-Unix-Plattform laufen haben und bei manchen Arbeitskopien nicht die gewünschte Zeilenendekennung erhalten, dann liegt das normalerweise daran, dass die Dateien aus Versehen mit der Option -kb hinzugefügt wurden. Im Archiv wird das, ob man es glaubt oder nicht, mit dem Kommando

behoben. Die Option -kkv besagt, dass normale Schlüsselwortersetzung durchgeführt werden soll, und impliziert auch die normale Zeilenendekonvertierung. (CVS ist intern betrachtet ein wenig wirr, wenn es um die Unterscheidung zwischen Schlüsselwortersetzung und Zeilenendekonvertierung geht. Das zeigt sich darin, dass man mit den -k-Optionen nicht beide Parameter festlegen kann.)

Leider behebt das admin-Kommando das Problem mit der Datei nur im Archiv - Ihre Arbeitskopie denkt immer noch, dass es sich um eine Binärdatei handelt. Sie können zwar die Zeile für diese Datei in CVS/Entries anpassen, sodass sie -kb nicht mehr enthält, aber das löst das Problem nicht in den anderen Arbeitskopien, die es sonst noch gibt.

Ich muss ein Unterverzeichnis aus meinem Projekt löschen. Wie stelle ich das an?

Tja, richtig löschen können Sie das Unterverzeichnis nicht, aber Sie können alle Dateien darin entfernen (indem Sie sie erst löschen, dann cvs remove und commit ausführen). Sobald das Verzeichnis leer ist, kann jeder es automatisch aus seiner Arbeitskopie heraus schneiden, indem er die Option -P beim update mit angibt.

Kann ich .cvspass-Dateien oder Teile davon kopieren?

Ja, das ist möglich. Man kann .cvspass-Dateien von Rechner zu Rechner kopieren, und man kann auch einzelne Zeilen aus einer .cvspass-Datei zur anderen kopieren. Bei Servern mit hoher Latenz kann das schneller gehen, als sich mittels cvs login bei jedem Rechner, der eine Arbeitskopie beheimatet, anzumelden.

Denken Sie daran, dass es vermutlich nicht funktionieren wird, wenn Sie eine .cvspass-Datei zwischen zwei Rechnern mit unterschiedlicher Zeilenendekennung transferieren. (Natürlich können Sie die Konvertierung wahrscheinlich ohne große Mühe manuell durchführen.)

Ich habe gerade einige Dateien mit der falschen Log-Nachricht committed.

Sie müssen nichts im Archiv von Hand editieren, um das zu korrigieren. Lassen Sie einfach admin mit der Option -m laufen. Bedenken Sie, dass Sie kein Leerzeichen zwischen die Option -m und ihr Argument setzen dürfen und dass Sie die Ersatzlog-Nachricht genau wie jede normale mit Anführungszeichen kapseln müssen:

Ich möchte Dateien verschieben, ohne die Revisionshistorie zu verlieren.

Kopieren Sie (nicht verschieben) die RCS-Dateien an den gewünschten neuen Platz im Projekt. Sie müssen zusätzlich an der alten Stelle verbleiben.

Führen Sie dann aus einer Arbeitskopie Folgendes aus:

Wenn jetzt jemand ein Update durchführt, dann wird CVS die alten Dateien richtigerweise entfernen und die neuen Dateien in die Arbeitskopie hineinbringen, so als ob sie ganz normal dem Archiv hinzugefügt worden wären (abgesehen davon, dass Sie für angeblich neue Dateien ungewöhnlich hohe Revisionsnummern haben).

Wie bekomme ich eine Liste aller Marken in einem Projekt?

Dafür gibt es in CVS momentan keine bequeme Möglichkeit. Alle Benutzer bekommen diesen Mangel schmerzlich zu spüren, und ich glaube, dass daran gearbeitet wird, diese Funktion verfügbar zu machen. Wenn Sie dies lesen, gibt es vielleicht schon ein Kommando cvs tags oder so ähnlich.

Bis es soweit ist, können Sie die Liste auch über Umwege erhalten. Führen Sie cvs log -h aus, und lesen Sie den Teil der Ausgabe, welcher der Kopfzeile symbolic names: folgt. Oder, falls Sie sich auf dem Rechner, auf dem das Archiv liegt, befinden, können Sie sich einfach den Anfang einiger der RCS-Dateien direkt im Archiv ansehen. Alle Marken (solche, die sich auf Entwicklungszweige beziehen, wie auch solche, die das nicht tun) sind im Feld symbols aufgeführt:

Wie bekomme ich eine Liste aller Projekte im Archiv?

Wie auch das Auflisten aller Marken, so ist diese Funktion in der aktuellen Version von CVS nicht implementiert, aber es ist sehr wahrscheinlich, dass es bald implementiert wird. Ich glaube, dass das Kommando cvs list oder kurz cvs ls genannt werden wird und dass es sowohl die Datei modules parsen wird, als auch die Unterverzeichnisse im Archiv auflisten wird.

In der Zwischenzeit fahren Sie wahrscheinlich am besten damit, sich die Datei CVSROOT/modules (entweder direkt oder mit checkout -c) anzusehen. Wenn allerdings noch niemand ein Modul für ein bestimmtes Projekt angelegt hat, wird es da auch nicht aufgeführt werden.

Manche Kommandos schlagen fehl, wenn sie remote ausgeführt werden, nicht aber lokal. Wie kann ich das Problem eingrenzen und beheben?

Es gibt hin und wieder Probleme mit der Kommunikation zwischen Client und Server. Wenn das der Fall ist, so handelt es sich um einen Fehler in CVS, aber wie soll man so etwas aufspüren?

CVS ermöglicht es, das Protokoll zwischen Client und Server mitzulesen. Bevor Sie das Kommando auf dem lokalen Rechner (mit der Arbeitskopie) ausführen, setzen Sie die Umgebungsvariable CVS_CLIENT_LOG. Die Bourne-Shell-Syntax dafür lautet so:

Sobald diese Variable gesetzt wurde, zeichnet CVS die gesamte Kommunikation zwischen Client und Server in zwei Dateien auf, deren Namen auf dem Namen in der Variablen basieren:

Die Datei clog.in enthält alles, was der Client zum Server geschickt hat, und clog.out enthält all das, was der Server zurück zum Client gesendet hat. Hier der Inhalt von clog.out, damit Sie eine Vorstellung von dem Protokoll erhalten:

     
Valid-requests Root Valid-responses valid-requests Repository \
Directory Max-dotdot Static-directory Sticky Checkin-prog Update-prog
\ Entry Kopt Checkin-time Modified Is-modified UseUnchanged Unchanged
\ Notify Questionable Case Argument Argumentx Global_option
Gzip-stream \ wrapper-sendme-rcsOptions Set expand-modules ci co
update diff log add \ remove update-patches gzip-file-contents status
rdiff tag rtag import \ admin export history release watch-on
watch-off watch-add watch-remove \ watchers editors init annotate noop
ok M ? clog.in M ? clog.out E cvs server: Updating .
E cvs server: Updating a-subdir
E cvs server: Updating a-subdir/subsubdir
E cvs server: Updating b-subdir
ok
     
     

Die Datei clog.in ist sogar noch komplizierter aufgebaut, da Revisionsnummern und andere dateibezogene Informationen zum Server geschickt werden müssen.

Ich habe hier nicht genug Platz, um das Client/Server-Protokoll zu dokumentieren, aber Sie können, wenn Sie eine vollständige Beschreibung wünschen, die Info-Seiten namens cvsclient lesen, die bei CVS mitgeliefert werden. Man kann wahrscheinlich eine Menge über das Protokoll herausfinden, wenn man es einfach roh liest. Wenngleich Sie wohl kaum anfangen werden, die Client/Server-Kommunikation zu untersuchen, bevor Sie nicht alle anderen möglichen Ursachen für ein Problem ausgeschlossen haben, ist es doch ein unschätzbar wertvolles Hilfsmittel, um herauszufinden, was wirklich zwischen den beiden vorgeht.

Ich konnte mein Problem nicht in diesem Kapitel beschrieben finden.

Mailen Sie eine vollständige und genaue Beschreibung Ihres Problems an info-cvs@gnu.org, das ist die Diskussions-Mailingliste von CVS. Ihre Mitglieder sind über viele Zeitzonen verteilt, und ich habe normalerweise innerhalb von ein bis zwei Stunden eine Antwort erhalten. Treten Sie der Liste bei, indem Sie eine E-Mail an info-cvs-request@gnu.org schicken, dann können auch Sie dabei helfen, Fragen zu beantworten.

Ich glaube, ich habe einen Fehler in CVS gefunden. Was mache ich?

CVS ist weit davon entfernt, perfekt zu sein - wenn Sie die Dokumentation schon gelesen und auch die Frage auf der Mailingliste erörtert haben und immer noch glauben, dass Sie einen Fehler vor sich haben, dann ist das vermutlich auch der Fall.

Schicken Sie eine so komplette Beschreibung wie möglich an bug-cvs@gnu.org. (Sie können auch dieser Liste beitreten, verwenden Sie einfach stattdessen bug-cvs-request.) Stellen Sie sicher, dass Sie Ihre Versionsnummer von CVS beifügen (sowohl die Client- als auch die Serverversion, falls von Bedeutung) sowie ein Rezept, wie der Fehler reproduziert werden kann.

Wenn Sie einen Patch geschrieben haben, der den Fehler behebt, dann fügen Sie ihn bei und erwähnen das auch im Betreff der E-Mail. Die Betreuer werden Ihnen sehr dankbar sein.

(Weitere Details über diese Vorgänge sind unter BUGS im Cederqvist und in der Datei HACKING in der Quelltextdistribution von CVS umrissen.)

Ich habe ein neues Feature für CVS implementiert, wem schicke ich das?

Gleiche Vorgehensweise wie bei einem Fehler: Schicken Sie den Patch an bugs-cvs@gnu.org. Lesen Sie aber zuerst die Datei HACKING.

3.2 Die Dinge ändern sich

Die Techniken der Fehlerbeseitigung und die bekannten Fehler, die in diesem Kapitel beschrieben worden sind, waren (ungefähr) zu Zeiten von CVS Version 1.10.7 zutreffend. In der Welt von CVS bewegt sich aber alles sehr schnell. Als ich die letzten paar Kapitel geschrieben habe, ist der inoffizielle Mantel der CVS-Betreuung von Cyclic Software auf SourceGear, Inc. ( www.sourcegear.com) übergegangen, denn diese haben Cyclic aufgekauft. SourceGear hat öffentlich verkündet, dass sie beabsichtigen, eine aktive Rolle bei der CVS-Betreuung zu übernehmen, und hat die Zustimmung von Cyclic erhalten, was (mehr oder weniger) ausreicht, um sie zu den derzeitigen »Hauptbetreuern« von CVS zu machen. (Die Adresse  www.cyclic.com bleibt aber erhalten, sodass alle URLs, die vorher in diesem Buch angegeben wurden, ihre Gültigkeit behalten.)

SourceGear ist momentan damit beschäftigt, die verschiedenen Patches, die noch herumfliegen, zu bereinigen und zu organisieren, mit der Absicht, viele davon in CVS zu integrieren. Manche dieser Patches werden wahrscheinlich Fehler beheben, die ich schon aufgelistet habe, und manche werden den Anwendern von CVS neue Mittel zur Fehlerbehebung bieten.

Die beste Möglichkeit, um up-to-date mit dem, was da vorgeht, zu bleiben, ist die Datei NEWS in Ihrer CVS-Distribution zu lesen, die Mailinglisten zu beobachten und Änderungen im Cederqvist und in der Online-Version einiger der Kapitel aus diesem Buch zu verfolgen.

1. Anm. d. Übers.: Schwarze (geschlossene) Kiste
2. Anm. d. Übers.: »Nonbranch Sticky Tag«
3. Anm. d. Übers.: Von jederman beschreibbar
4. Anm. d. Übers.: Häufig gestellte Fragen
5. Anm. d. Übers.: User ID
6. Anm. d. Übers.: Im Deutschen auch Rückstrich genannt: »\«.
7. Anm. d. Übers.: Batch-Dateien, um ein anderes »deutsches« Wort zu bemühen. Stapelverarbeitungsdateien, wenn's denn unbedingt sein muss.