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
cvs update: [22:58:26] waiting for qsmith's lock in /usr/local/newrepos/myproj
|
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:
/etc/inetd.conf
|
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:
etc/services
|
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:
user@linux ~$
ls -l /usr/local/newrepos/someproj
total 6 -r--r--r-- 1 jrandom users 630 Aug 17 01:10 README.txt,v -r-xr-xr-x 1 jrandom users 1041 Aug 17 01:10 scrub.pl,v* -r--r--r-- 1 jrandom users 750 Aug 17 01:10 hello.c,v
|
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
Die Zugriffsrechte im Archiv behalten immer die Oberhand. Wenn also
eine Datei im Archiv nicht ausführbar ist, in der Arbeitskopie aber
schon, dann wird die Datei in der Arbeitskopie nach einem Update
nicht mehr ausführbar sein. Die Tatsache, dass sich die Zugriffsrechte
der Dateien still und heimlich ändern können, kann ziemlich
frustrierend sein. Wenn das geschieht, sollten Sie als Erstes das
Archiv überprüfen, um zu sehen, ob Sie das Problem lösen können,
indem Sie dort die Zugriffsrechte der entsprechenden RCS-Dateien
setzen.
|
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:
Datei .cvspass
|
set HOME=C:
|
Das aber nicht:
Datei .cvspass
|
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
Datei .cvspass
|
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
user@linux ~$
cvs update -r HEAD
|
oder
user@linux ~$
cvs update -A
|
aus dem Hauptverzeichnis aus. Wenn Sie hingegen Ihre ganze
Arbeitskopie auf eine bestimmte Entwicklungslinie setzen wollen,
führen Sie Folgendes aus:
user@linux ~$
cvs update -r Name_des_Zweiges
|
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
cvs [export aborted]: cannot write /usr/local/myproj/CVSROOT/val-tags: \ Operation not permitted
|
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:
user@linux ~$
cvs update -r Name_der_Marke
|
oder
user@linux ~$
cvs checkout -D "1999-08-16"
|
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
user@linux ~$
cvs update -A
|
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:
user@linux ~$
cvs co -d bwf-misc user-space/bwf/writings/misc
cvs server: cannot find module 'user-space/bwf/writings/misc' - ignored cvs [checkout aborted]: cannot expand modules
|
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:
user@linux ~$
ls -ld /usr/local/cvs/user-space/bwf
drwx------ 19 bwf users 1024 Aug 17 01:24 bwf/
|
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
user@linux ~$
cvs watch remove
|
für alle Dateien aufgerufen, aber vergessen, ebenfalls
user@linux ~$
cvs watch off
|
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:
user@linux ~$
cvs admin -kb foo.gif
|
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
user@linux ~$
cvs admin -kkv DATEI
|
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:
user@linux ~$
cvs admin -m1.17:"I take back what I said about the customer." hello.c
|
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:
user@linux ~$
rm alte_Datei_1 alte_Datei_2 ...
user@linux ~$
cvs remove alte_Datei_1 alte_Datei_2 ...
user@linux ~$
cvs commit -m "removed from here" alte_Datei_1 alte_Datei_2 ...
|
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:
user@linux ~$
head /usr/local/newrepos/hello.c,v
head 2.0; access; symbols Release_1_0:1.22 Exotic_Greetings-2:1.21 merged-Exotic_Greetings-1:1.21 Exotic_Greetings-1:1.21 merged-Exotic_Greetings:1.21 Exotic_Greetings-branch:1.21.0.2 Root-of-Exotic_Greetings:1.21 start:1.1.1.1 jrandom:1.1.1; locks; strict; comment @ * @;
|
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:
user@linux ~$
CVS_CLIENT_LOG=clog; export CVS_CLIENT_LOG
|
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:
user@linux ~$
ls
CVS/ README.txt a-subdir/ b-subdir/ foo.gif hello.c cvs update ? clog.in ? clog.out cvs server: Updating . cvs server: Updating a-subdir cvs server: Updating a-subdir/subsubdir cvs server: Updating b-subdir
user@linux ~$
ls
CVS/ a-subdir/ clog.in foo.gif README.txt b-subdir/ clog.out hello.c
user@linux ~$
|
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:
clog.out
|
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.
|