[Logo der Universität Bayreuth]
Universität Bayreuth

Mathematisches
Institut
 Einleitung

 Erste Schritte

 Mail und News
 Drucken

 KDE

 LaTeX/TeX

 Linksammlung

 Linuxtools

 Netzwerk

 Programmieren

 Windows

 X Window
 Anträge

 Kontakt

 CVS <-

eigene CVS-FAQ

Sinn/wichtige Hinweise

Diese CVS-FAQ sollte ursprünglich speziell auf Erfahrungen und Probleme des Umgangs mit CVS innerhalb des Kurses "Computational Geometry" (WS 2001/2002) an der Universität Bayreuth eingehen. Bei der Beschreibung wird Wert gelegt auf die Besonderheiten des WAP-Pools Mathematik der Universität Bayreuth. Der unten verwendete CVS-Server bietet jedoch keinen anonymen Zugang und ist nur für registrierte Studierende und Bedienstete der Universität Bayreuth vorgesehen. Diese FAQ war daher weder umfassend geplant noch muss sie immer richtig sein ... . Allerdings ist sie durch viele Beispiele ergänzt worden. Sie profitierte vom Engagement der Studierenden, die an den Übungen teilgenommen haben sowie von den folgenden (vollständigeren) FAQs zu CVS
-> CVS FAQ von Xiombiot CVS Wiki
-> CVS Wiki von Xiombiot
-> CVS Clients (Xiombiot)
-> FAQ von CVS-Homepage (Cyclic Software)
Die Seite enthält zur Zeit kaum Referenzen. Die dort zitierte FAQ-O-Matic von Pascal Molli ist nicht mehr auffindbar.
-> CVS-Manual von Per Cederquist für CVS 1.11.1p1
   (lokaler Link, geht nur im WAP-Pool Mathematik (Raum 3.2.01.548, NW II)
und den Online-Manuals
-> -> Wikied Manual von CVS-Wiki (Ximbiot)
-> Manualübersicht vom CVS-Wiki
-> Manual von CVS-Wiki (HTML Cederqvist)
-> CVS Quick Reference
-> CVS for new users
-> Version Control with CVS (Ximbiot)
-> CVS Informationsseiten
-> Manual von FreeSoftware (non-GNU).

Homepages rund um CVS

-> CVS-Homepage bei Xiombiot
-> CVS-Archive bei Xiombiot
-> private CVS-Homepage von John Brown

Inhaltsverzeichnis

  1. Beiträge/Danksagung
  2. Was bedeutet CVS?
  3. Wie funktioniert CVS?
  4. Wo bekomme ich CVS her?
  5. Gibt es grafische Programme für die CVS-Benutzung?
  6. Gibt es CVS auch unter Windows?
  7. Was muss ich beim ersten Mal beachten, wenn ich CVS nutzen will?
  8. Kann ich bei CVS auf einen CVS-Server verzichten bzw. kann ich CVS nutzen, ohne an einem CVS-Server registriert zu sein?
  9. Wie kann ich CVS ausprobieren, ohne etwas an einem CVS-Modul zu ändern?
  10. Welche Dateien/Verzeichnisse kann ich mit CVS verwalten?
  11. Was muss ich tun, um mit CVS den neuesten Stand eines Moduls/Projektes abzurufen?
  12. Wo ist der Vorteil zu FTP?
  13. Was für Dateien entstehen eigentlich lokal?
  14. Was passiert, wenn ich versehentlich lokal eine am CVS-Server gespeicherte Datei oder ein Unterverzeichnis gelöscht habe?
  15. Wie kann ich eine vorhandene Datei in einem CVS-Modul ändern und diese Änderung veröffentlichen?
  16. Wie kann ich eine neue Datei zum CVS-Modul hinzufügen?
  17. Wie kann ich ein neues Unterverzeichnis zum CVS-Modul hinzufügen?
  18. Kann ich Dateien aus dem CVS-Modul löschen oder umbenennen?
  19. Kann ich Unterverzeichnisse aus dem CVS-Modul löschen oder umbenennen?
  20. Warum muss ich vorher "cvs add" bei Dateien machen, wenn ich nachher sowieso noch "cvs commit" eingeben muss?
  21. Kann ich CVS von daheim aus so verwenden, dass ich meine Änderungen von daheim aus an den CVS-Server schicken kann?
  22. Kann man beim ersten Mal nur einen Teil des CVS-Moduls übertragen?
  23. Wie komme ich an alte Versionen?
  24. Was muss ich tun, damit ich später einmal eine ältere Version meines Moduls/Unterverzeichnisses abrufen kann?
  25. Was passiert, wenn man eine Datei aus dem Modul entfernt und eine ganz andere mit demselben Namen in das Modul einfügen will?
  26. Wie kann man ein binäres File mit CVS verwalten?
  27. Wie kann man selbst auf einem Linux-Rechner einen CVS-Server etablieren?
  28. Wie kann Files, die mit RCS verwaltet werden, auf CVS-Verwaltung umstellen?
  29. Wie kann man Files für die Utilities "patch" bzw. "ed" aus CVS erzeugen?
  30. Wie kann man ein unbeabsichtigtes Warten auf einen behobenen Lock-Zustand am CVS-Server beenden?
  31. Wer setzt CVS ein?

  1. Beiträge/Danksagungen

    Ich bedanke mich ausdrücklich bei den folgenden Personen für kritische und nützliche Anmerkungen zu dieser eigenen CVS-FAQ:

    • Übungsteilnehmerinnen und -teilnehmer des Kurses "Computational Geometry" (WS 2001/2002) an der Universität Bayreuth, insbesondere bei
      Gilbert Perria
    • Michael Butscher
    • Frithof Meyer

    Bei Anmerkungen/Kritik bitte eine e-mail an

    Robert Baier ([1. e-mail-Adresse])
    senden.

    top top

  2. Was bedeutet CVS?

    CVS steht für Concurrent Versions System, also eine Software zur netzweiten Versionsverwaltung von Dokumenten.

    top top

  3. Wie funktioniert CVS?

    CVS ist eine Client-Server-Anwendung.

    Der CVS-Server ist im WAP-Pool der Fileserver btcipmatx15.cip.uni-bayreuth.de. Er verwaltet in einem CVS-Root-Verzeichnis (am WAP-Pool: /share/cvs-repository) in zahlreichen Unterverzeichnissen (in CVS Module genannt) die Versionen, Kommentare zu den Versionen und ermöglicht das Vergleichen, Abrufen von alten und neuen Versionen und das Veröffentlichen von aktuell erstellten Versionen.

    Der CVS-Client heißt unter Linux einfach cvs. Mit zahlreichen Argumenten ermöglicht er durch den Kontakt mit dem CVS-Server über ein CVS-Protokoll das Vergleichen, Abrufen von alten und neuen Versionen und das Veröffentlichen von aktuell erstellten Versionen.

    Als CVS-Protokoll bieten sich pserver, rsh und rsh an. Am WAP-Pool wird das Protokoll pserver verwendet für die Kommunikation zwischen CVS-Server und CVS-Client.

    Alle Einstellungen zu CVS-Protokoll, CVS-Server und CVS-Rootverzeichnis stehen praktischerweise in der Environment-Variable CVSROOT, siehe Frage zu Environment-Variablen.

    top top

  4. Wo bekomme ich CVS her?

    In jeder normalen Linux-Distribution sollte es ein CVS-Paket geben, dass man ggf. nachinstallieren muss (in SuSE mit yast/yast2). Am WAP-Pool ist der CVS-Client "cvs" schon installiert.
    Den Sourcecode zu CVS und Binaries für gängige Betriebssysteme (Win32, Linux, MacOS, ...) kann man unter Downloads des CVS-Projekts unter "Documents & Files/ccvs/binaries" herunterladen. Es gibt auch (mehrere) Windows-Versionen von CVS.

    top top

  5. Gibt es grafische Programme für die CVS-Benutzung?

    Es gibt u.a. folgende grafische Programme, die den Umgang mit CVS erleichtern:

    Name des Programms nötiges Betriebssystem Besonderheiten Entwicklungsgruppe
    Cervisia bzw. Cervisia-Projekt unter Sourceforge Linux/BSD/... (graf.) KDE-Frontend für CVS Development-Team des Cervisia-Projekts
    gCVS Linux/Solaris/FreeBSD graf. CVS-Client unter GPL CvsGui-Projekt
    jCVS (fast) alle, benötigt JRE 1.4 in Java geschrieben, unterstützt SSH
    jCVSWeb ist Webapplikation (z.B. für Tomcat-Server), jCVS Servlet eine Servlet-Entwicklung     		Entwicklungsteam des Projekts/Timothy Gerard Endres
    LinCVS XXL bzw. LinCVS-Projekt bei Sourceforge Linux/Solaris/MacOS/Win32 frei nur für nichtkommerzielle Zwecke GbR Tilo Riemer & Frank Hemer
    WinCVS Win32 graf. CVS-Client unter GPL CvsGui-Projekt

    In einige GUI-Programme kann man grafische Vergleichsprogramme einbinden wie z.B.

    Name des Programms nötiges Betriebssystem
    KDiff (veralteter Vorgänger von Kompare) Linux mit KDE 3/MS-Windows
    KDiff3 Linux mit KDE 3/MS-Windows/Unix mit Qt
    Kompare (KDE-Nachfolger von KDiff) Linux mit KDE 3
    WinMerge Win32

    top top

  6. Gibt es CVS auch unter Windows?

    Ja, am besten schaue man unter CVS-Win32-Binaries (CVS-Projekt) nach. Dort gibt es den aktuellen (spartanischen) CVS-ASCII-Client "cvs.exe" (im ZIP-File bei den Win32-Binaries) und Hinweise auf andere grafische CVS-Clients.
    Der grafische Client WinCVS vom CvsGui-Projekt (alternativ: CvsGui-Projekt bei Sourceforge; früher: www.cvsgui.org) ist ein gutes Programm für Windows-Betriebssysteme.
    Als (grafisches) Programm bei Vergleichen verschiedener Versionen kann man WinMerge in WinCVS integrieren.

  7. Was muss ich beim ersten Mal beachten, wenn ich CVS nutzen will?

    Fazit:
    Man muss folgende Schritte machen:

    • Zugehörigkeit zur Benutzergruppe cvs sicherstellen
    • Environment-Variablen CVSROOT und CVSEDITOR setzen und diese zum Startup-File der Shell hinzufügen
    • CVS-Kommando cvs login
    • CVS-Kommando cvs checkout <Modul>

    Im Detail:

    • Der Superuser muss mich zur Benutzergruppe (am WAP-Pool: cvs) hinzufügen, damit ich CVS prinzipiell benutzen kann.
      Er muss mich ebenfalls zur Benutzergruppe (am WAP-Pool: cgal) hinzufügen, damit ich ein spezielles CVS-Unterverzeichnis lesen kann, das die CGAL-Informationen enthält.
      Als letztes muss er ein CVS-Password (am WAP-Pool: das zum Zeitpunkt der Aufnahme in die CVS-Passworddatei gültige WAP-Pool-Password) in eine interne CVS-Password-Datei eintragen.

    • Man selbst sollte zwei Environment-Variablen setzen, die den Umgang mit CVS wesentlich erleichtern. Environment-Variablen werden in der Shell gesetzt und vom CVS-Client ausgewertet.
      Die Environment-Variable CVSROOT gibt den CVS-Usernamen (am WAP-Pool: der normale Benutzername), den CVS-Server, das verwendete CVS-Protokoll und das CVS-Root-Verzeichnis an.

      Beispiel:
      Setzen von CVSROOT für den User cgeom02 mit der Bash als Shell: 

          CVSROOT=":pserver:cgeom02@btcipmatx15.cip.uni-bayreuth.de:/share/cvs-repository"
    export CVSROOT

      Da man Versionsänderungen unbedingt kommentieren sollte, startet der CVS-Client automatisch einen Editor. Als Standard vi, einen Editor mit etwas gewöhnungsbedürftigen Kommando- und Editormodi. Um stattdessen den eigenen Lieblingseditor zu verwenden, setzt man besser die Environment-Variable CVSEDITOR.
      Um z.B. den Editor nedit zu verwenden, setzt man 
          CVSEDITOR=/usr/bin/X11/nedit
    export CVSEDITOR
      Um den genauen Pfad des Lieblingseditors zu erfahren, kann man z.B. folgendes machen: 
          whereis nedit
    # liefert das Ergebnis:
    nedit: /usr/X11R6/bin/nedit /usr/X386/bin/nedit /usr/bin/X11/nedit /usr/X11/bin/nedit
           /usr/X386/man/man1/nedit.1.gz /usr/X11/man/man1/nedit.1.gz
      Da das Executable nedit durch Links in vier verschiedenen Stellen zu finden ist, kann eine der ersten vier Antworten genommen werden, die anderen beiden Antworten vom Unix-Befehl whereis sind nur die Manual-Seiten.

      Tipp:
      Damit man nicht in jedem neuen Terminalfenster/Shell die obigen Befehle eingeben muss, fügt man diese Befehle am besten ganz ans Ende der Datei $HOME/.bashrc ein, die beim Start jeder Shell/jedes Terminalfensters gelesen und interpretiert wird. 

          # Bash knows ... (1. Zeile von .bashrc)
    ...
    export DISPLAY LESS PS1 PS2
    umask 022 (Ende von .bashrc)
    # lokale Aenderungen fuer CVS:
    CVSEDITOR=/usr/bin/X11/nedit
    CVSROOT=":pserver:cgeom02@btcipmatx15.cip.uni-bayreuth.de:/share/cvs-repository"
    export CVSEDITOR CVSROOT
      Achtung:
      Jegliche Änderung der Datei $HOME/.bashrc wirkt sich erst auf zukünftig gestartete Terminalfenster/Shells aus und nicht schon auf das aktuelle Terminalfenster/Shell. Deshalb sollte man unbedingt ein neues Terminalfenster/Shell starten. Wenn man sich einmal ausgeloggt und wieder eingeloggt hat, gibt es dieses Problem nicht mehr ... .

    • Man muss sich einmalig bei CVS anmelden. Dies geschieht durch den Befehl 

          cvs login
      Es erscheint für den User cgeom02 die Frage 
          (Logging in to cgeom02@btcipmatx15.cip.uni-bayreuth.de)
    CVS password:
      Bei korrekter Eingabe des CVS-Passwords passiert weiter nichts, nur bei falscher Eingabe (oder auch beim falschen Setzen der Environment-Variable CVSROOT) kommt die Meldung 
          cvs [login aborted]: authorization failed: \
      server btcipmatx15.cip.uni-bayreuth.de rejected access
      Es entsteht bei korrekter Eingabe die Datei $HOME/.cvspass. Solange man sie nicht löscht, muss man diese Login-Prozedur nicht mehr durchführen.

      Warnung:
      Diese nur für den Benutzer lesbare Datei enthält eine schlecht verschlüsselte Version des CVS-Passwords. Man sollte diese Datei also geheim halten!

    • Jetzt sollte man ein eigenes lokales CVS-Arbeitsverzeichnis erstellen (am WAP-Pool z.B. $HOME/cvs-work durch den Unix-Befehl mkdir $HOME/cvs-work) und in dieses Unterverzeichnis durch den Unix-Befehl cd $HOME/cvs-work für alles weitere wechseln.

    • Jetzt kann man einmalig ein neues CVS-Modul/CVS-Projekt auschecken. Für diese Vorlesung sind die CVS-Module CGAL (Vorlesung/Übung zu Computational Geometry) und test (zum Testen von CVS-Befehlen, hat ansonsten keinen Zweck). Nach dem Wechseln in das lokale CVS-Verzeichnis $HOME/cvs-work gibt man ein: 

          cvs checkout CGAL
      Dann werden automatisch alle Files und Subdirectories des CGAL-Moduls in der momentan aktuellen Fassung erstellt. Der CVS-Server hat dieses Modul mit allen Versionsinformationen am WAP-Pool unter /share/cvs-repository/CGAL abgespeichert.

    top top

  8. Kann ich bei CVS auf einen CVS-Server verzichten bzw. kann ich CVS nutzen, ohne an einem CVS-Server registriert zu sein?

    Ja, das geht (ist eigentlich ganz einfach). Allerdings hat man dann zwei wichtige CVS-Unterverzeichnisse lokal am Rechner: erstens das lokale CVS-Server-Repository (im folgenden unter "$HOME/cvs-local-rep"), in dem CVS die Versionsunterschiede, die Kommentare zu den Versionen und die Konfigurationsfiles speichert und zweitens das lokale CVS-Arbeitsverzeichnis (im folgenden unter "$HOME/cvs-work"), in dem man die mit CVS verwalteten Files auscheckt, bearbeitet, neue Versionen veröffentlicht, ... .
    Außerdem sollte es einem klar sein, dass das nur Sinn macht, wenn man alleine auf einem Rechner entwickelt. Sollte man gleichzeitig auf mehreren Rechnern alleine oder gar in einem Team entwickeln, ist es normalerweise immer sinnvoll, einen eigenen CVS-Server zu nutzen, um nicht auf einen Rechner festgelegt zu sein.

    Fazit:
    Man muss folgende Schritte machen:

    • Anlegen eines neuen Verzeichnisses (z.B. "$HOME/cvs-local-rep")
    • Setzen der Environment-Variable CVSROOT auf 
          export CVSROOT=:local:$HOME/cvs-local-rep # (Bash)
    • Erzeugen der nötigen Files für das lokale CVS-Server-Repository mit "cvs init"
    • Einbringen schon vorhandener Files in das lokale CVS-Server-Repository mit "cvs import"
    • Auschecken dieser Files im lokalen CVS-Arbeitsverzeichnis mit "cvs checkout"

    Im Detail: Man muss folgende Schritte machen:

    • Anlegen eines neuen Verzeichnisses (z.B. "$HOME/cvs-local-rep") für das lokale CVS-Repository: 
          mkdir $HOME/cvs-local-rep
    • Setzen der Environment-Variable CVSROOT auf Protokoll "local" und Spezifikation des lokalen CVS-Repositories, z.B. 
          # unter der Bash-Shell:
    export CVSROOT=:local:$HOME/cvs-local-rep
    • Erzeugen der nötigen Files für das lokale CVS-Server-Repository mit "cvs init" 
          # Kommando gibt normalerweise nichts aus
    cvs init
    # Ansehen des neuen lokalen CVS-Server-Repositories
    ll $HOME/cvs-local-rep
    # typische Ausgabe:
    insgesamt 1
    drwxrwxr-x 2 btm506 users 900 Apr 11 09:58 CVSROOT
      Es entsteht im lokalen CVS-Server-Repository das neue Unterverzeichnis "CVSROOT", das alle wesentlichen Files zur Benutzung des lokalen "CVS-Servers" enthält.
      Es enthält aber kein File "passwd", so dass im folgenden ein "cvs login" überflüssig ist. 
          # "cvs login" braucht man nicht
    cvs login
    # typische Ausgabe:
    cvs login: can only use pserver method with `login' command
    cvs [login aborted]: CVSROOT: :local:/home/btm506/cvs-local-rep
    • Einbringen schon vorhandener Files in das lokale CVS-Server-Repository mit "cvs import", z.B. 
          # Files und Unterverzeichnisse unter $HOME/programme
    # sollen unter CVS-Verwaltung
    cd $HOME/programme
    # nur zwei Files im Verzeichnis: "Readme.txt" und "prog_1.cpp"
    ll
    # typische Ausgabe:
    insgesamt 20
    -rw-r--r-- 1 btm506 users 2328 Apr 11 10:16 Readme.txt
    -rw-r--r-- 1 btm506 users 15122 Apr 11 10:16 prog_1.cpp
    # neues CVS-Modul für die Files soll "progs" heißen
    # Option "-m": CVS-Kommentar für 1. Version
    # name: sog. Vendor-Tag, d.h. symbolische Bezeichnung
    # fuer 1. Entwicklungszweig (first-level branch)
    # Da "vendor" im CVS-Terminus der Hersteller/Entwickler
    # der Dateien ist, kann man hier seinen eigenen Nachnamen
    # spezifizieren
    # start: sog. Release-Tag, d.h. symbolische Bezeichnung
    # fuer 1. Import des 1. Entwicklungszweig (first leave)
    # Man verwendet üblicherweise "start" als Release-Tag
    cvs import -m "meine Programme" progs nachname start
    # typische Ausgabe:
    N progs/prog_1.cpp
    N progs/Readme.txt
    No conflicts created by this import
    # es entsteht unter dem lokalen CVS-Server-Repository das neue
    # Unterverzeichnis $HOME/cvs-work/progs
    ll $HOME/cvs-local-rep
    # typische Ausgabe:
    drwxrwxr-x 2 btm506 users 900 Apr 11 10:11 CVSROOT
    drwxrwxr-x 2 btm506 users 91 Apr 11 10:16 progs
    ll $HOME/cvs-local-rep/progs
    # typische Ausgabe:
    insgesamt 20
    -r--r--r-- 1 btm506 users 2711 Apr 11 10:16 Readme.txt,v
    -r--r--r-- 1 btm506 users 15507 Apr 11 10:16 prog_1.cpp,v
    • Auschecken dieser Files im lokalen CVS-Arbeitsverzeichnis mit "cvs checkout" 
          # ins lokalen CVS-Arbeitsverzeichnis wechseln
    cd $HOME/cvs-work
    # Auschecken der mit "cvs import" eingestellten Version
    cvs checkout progs
    # typische Ausgabe:
    cvs checkout: Updating progs
    U progs/Readme.txt
    U progs/prog_1.cpp

    top top

  9. Wie kann ich CVS ausprobieren, ohne etwas an einem CVS-Modul zu ändern?

    Fazit: Die entscheidenden Kommandos sind:

    • cvs checkout <Modul>

    Im Detail:
    Man legt einfach ein neues CVS-Modul an, mit dem man die CVS-Kommandos für dieses CVS-Modul ausprobiert. Am WAP-Pool ist bereits ein CVS-Modul namens "test" dafür vorgesehen. Dieses dient ausschließlich zum Testen von CVS-Kommandos. Man checkt dieses einmal aus wie unter Checkout beschrieben und testet in diesem CVS-Modul, was man eigentlich in einem anderen CVS-Modul vorhat.

    Beispiel: 

        cd $HOME/cvs-work
    # Auschecken vom CVS-Modul "test"
    cvs checkout test
    # Wechseln in das lokale Arbeitsverzeichnis fuer das CVS-Modul "test"
    cd test
    # Test der CVS-Kommandos dort
    ...

    top top

  10. Welche Dateien/Verzeichnisse kann ich mit CVS verwalten?

    Am meisten Sinn macht es, Textdateien mit CVS zu verwalten. Prinzipiell ist es auch möglich, Binärdateien unter CVS-Verwaltung zu stellen (vgl. zugehörige Frage), allerdings muss man diese ggf. als Binärdateien kennzeichnen bei CVS-Aufrufen. Sinnlos ist es, Executables, Objectfiles oder Ähnliches in CVS aufzunehmen, da man diese immer aus den Quelldateien wieder erstellen kann. Solche Files benötigen nur Speicherplatz am CVS-Server ... .

    Als Anwendungsfälle kann man die Entwicklung eines Programmes/einer Programmbibliothek nennen (vor allem dann, wenn man das in einem Team macht, aber auch, wenn man das Programm selbst entwickelt, ist das sinnvoll), die Erstellung der Diplomarbeit in LaTeX oder von Dokumentationen, der Austausch von Textdateien in einem Team, ... .

    Immer muss man jedoch das Verzeichnis, in dem die Files/Unterverzeichnisse stehen, bereits unter CVS-Verwaltung gestellt haben. Dies erkennt man leicht daran, dass es ein Unterverzeichnis "CVS" gibt, in dem die Files

    • Entries
    • Repository
    • Root

    stehen (vgl. die Antwort zur Frage zu den entstehenden lokalen Files). Das Unterverzeichnis und die genannten Files sollte man keinesfalls löschen oder modifizieren. Sie dienen CVS als interne Files und sind wichtig für das korrekte Ablaufen der CVS-Kommandos.

    Versucht man in einem Unterverzeichnis ohne CVS-Verwaltung CVS-Kommandos einzugeben, erscheinen Fehlermeldungen wie im folgenden Beispiel.

    Beispiel: 

        cd $HOME/work
    # kein Unterverzeichnis "CVS" vorhanden
    # --> keine CVS-Verwaltung des Verzeichnisses $HOME/work
    ll CVS
    # Typische Meldung:
    ls: CVS: Datei oder Verzeichnis nicht gefunden
    # Fehler mit "update", da Verzeichnis nicht unter CVS-Verwaltung
    cvs update
    # Typische Meldung:
    cvs update: in directory .:
    cvs [update aborted]: there is no version here;
      run 'cvs checkout' first
    # Verzeichnis enthält File "test.cpp"
    ll test.cpp
    # Typische Meldung:
    -rw-r--r-- 1 btm506 users 4870 Feb 10 15:06 test.cpp
    # Fehler mit "add", da Verzeichnis nicht unter CVS-Verwaltung
    cvs add test.cpp
    # Typische Meldung:
    cvs add: cannot open CVS/Entries for reading:
      Datei oder Verzeichnis nicht gefunden
    cvs [add aborted]: no repository
    Eines der wenigen CVS-Kommandos, die funktionieren, wäre z.B. der Befehl "cvs checkout test". Dieser legt ja auch selbst das interne CVS-Unterverzeichnis "CVS" an.

    top top

  11. Was muss ich tun, um mit CVS den neuesten Stand eines Moduls/Projektes abzurufen?

    Fazit: Die entscheidenden Kommandos sind:

    • cvs update
    • cvs update -d

    Im Detail:
    Nach allen einmaligen Aktionen aus "Frage: CVS zum 1. Mal benutzen" muss man für das CVS-Modul CGAL nur in das lokale CVS-Modulverzeichnis $HOME/cvs-work/CGAL wechseln, das durch einen Checkout entstanden ist. Dann gibt man einfach 

        cvs update -d
    ein. Dies führt einen kompletten Update aller vorhandenen Dateien und Unterverzeichnisse des Moduls CGAL durch. Die Option "-d" bewirkt, dass auch neue Unterverzeichnisse und alle darin enthaltenen Dateien vom CVS-Server mit heruntergeladen werden.

    Warnung:
    Solange man nichts an den lokal gespeicherten Dateien geändert hat, kann auch keine eigene Arbeit verloren gehen.
    Hat man etwas an lokal gespeicherten Dateien unterhalb des Verzeichnisses $HOME/cvs-work/CGAL geändert, wird auch nichts überschrieben. U.U. wird aber der am CVS-Server gespeicherte Stand und die lokal vorhandene Datei auf einen gemeinsamen Stand gebracht. Dies nennt man Mergen. Gelingt dies nicht, kommt es zu sog. Konflikten. Lokale Änderungen gehen aber nie verloren, u.U. werden einfach nur sich widersprechende Teile vom CVS-Server und von der lokalen Datei hintereinander mit spezieller Markierung in die lokale Datei aufgenommen.

    top top

  12. Wo ist der Vorteil zu FTP?

    Das einfache Herunterladen des CVS-Moduls mit allen Dateien/Unterverzeichnissen (wie in "Frage zu Update von CVS-Modulen") beschrieben, ist natürlich nicht das einzige, was CVS bieten kann.
    CVS verwaltet und merkt sich nicht nur die aktuellste Fassung einer Datei, sondern auch alle bisher entstandenen Versionen und die Unterschiede zwischen den Versionen. Es ist daher auch in der Lage, alte Versionen wieder aus diesen Unterschieden zu erzeugen. Zudem ist es wie FTP netzweit erreichbar, man braucht keine Login-Berechtigung für den CVS-Server und kann auch von daheim aus (z.B. unter Windows mit einer offenen DFÜ-Verbindung) CVS-Kommandos ausführen.

    top top

  13. Was für Dateien entstehen eigentlich lokal?

    Fazit:

    • $HOME/.cvspass
    • $HOME/cvs-work
    • Unterverzeichnisse CVS

    Im Detail:

    • Beim Einloggen in CVS (vgl. Frage 3 zu "cvs login") entsteht automatisch im Homeverzeichnis die Datei ".cvspass", die den Wert der Environment-Variable CVSROOT (d.h. Informationen zum CVS-Server, zum CVS-Rootverzeichnis und zum CVS-Protokoll) sowie das (schlecht) verschlüsselte CVS-Password enthält. Diese Datei sollte nicht gelöscht werden.

    • Man muss selbst ein lokales CVS-Arbeitsverzeichnis anlegen, am WAP-Pool meist das Unterverzeichnis "$HOME/cvs-work" vom Homeverzeichnis des Users (vgl. Frage 3 zum CVS-Arbeitsverzeichnis).

    • Durch einen Checkout oder durch rekursives Update entsteht in jedem neu angelegten Unterverzeichnis des CVS-Moduls das interne CVS-Verwaltungsverzeichnis "CVS", das die Files "Entries" (enthält Unterverzeichnisse und Dateinamen mit Versionsnummern), "Repository" (enthält CVS-Modulnamen) und "Root" (beinhaltet Wert der Environment-Variable CVSROOT) enthält. Diese Files sollte man tunlichst nicht ändern oder gar löschen.
      Zusätzlich werden dadurch i.d.R. unterhalb des lokalen CVS-Arbeitsverzeichnisses neue Dateien und Unterverzeichnisse entstehen. (vgl. Frage zum Checkout und Frage zum Update).

    top top

  14. Was passiert, wenn ich versehentlich lokal eine am CVS-Server gespeicherte Datei oder ein Unterverzeichnis gelöscht habe?

    Gar nichts oder nicht viel!
    Kaputt gegangen oder etwas gelöscht wurde nur im lokalen CVS-Arbeitsverzeichnis, am CVS-Server ist alles beim alten geblieben. Im allerschlimmsten Fall hat man seine eigenen Änderungen an Dateien des CVS-Moduls verloren, an alten Versionen oder gar an Dateien des CVS-Moduls hat man gar nichts geändert. Im Gegenteil: Mit Hilfe des Updates kann man sofort wieder alle Dateien und Unterverzeichnisse des CVS-Moduls wieder herstellen.

    Beispiel: 

        cd $HOME/cvs-work/CGAL
    # versehentliches Loeschen vom Unterverzeichnis "help"
    rm -rf help
    # versehentliches Loeschen von Datei "ws2001_02.html"
    rm ws2001_02.html
    # Wiederherstellen der Datei "ws2001_02.html"
    # und vom Unterverzeichnis "help"
    cvs update -d

    top top

  15. Wie kann ich eine vorhandene Datei in einem CVS-Modul ändern und diese Änderung veröffentlichen?

    Fazit: Die entscheidenden Kommandos sind:

    • cvs commit
    • cvs commit <Filename(n)>

    Im Detail: Dies setzt voraus, dass die Datei schon zum CVS-Modul gehört (ansonsten siehe neues Hinzufügen von Dateien). (Das sind alle Dateien, die durch einen Checkout oder durch (rekursives) Update vom CVS-Server heruntergeladen wurden.)
    Ganz einfach irgendeinen Editor aufmachen, die Änderungen machen und dann veröffentlichen durch das CVS-Kommando "commit". Für das File "cvs_faq.html" in "$HOME/cvs-work/CGAL/help" lautet der Befehl 

        cvs commit cvs_faq.html
    wenn man bereits im Unterverzeichnis "$HOME/cvs-work/CGAL/help" ist. Es geht dann der Editor auf (standardmäßig der Vi-Editor bzw. der Editor, der in der Environment-Variable CVSEDITOR) festgelegt wurde). In dieser temporären Datei sollte man unbedingt die gemachten Änderungen sinnvoll, aber nicht zu lang (etwa 2-10 Zeilen) beschreiben, die Datei abspeichern und abwarten, ob das Veröffentlichen gelingt. Im Falle des Gelingens ist man fertig, die neue Version wurde vom CVS-Version abgespeichert. Bei Nichtgelingen ist man im Konfliktfall (siehe spätere Fragen).

    top top

  16. Wie kann ich eine neue Datei zum CVS-Modul hinzufügen?

    Fazit: Die entscheidenden Kommandos sind:

    • cvs add
    • cvs commit
    • cvs commit <Filename(n)>

    Im Detail:
    Man muss zunächst durch den CVS-Befehl "add" dem CVS-Server ankündigen, dass die neue Datei hinzugefügt werden soll. Danach muss man diese wie in der Frage zum Ändern von Dateien im CVS-Modul beschrieben, veröffentlichen.

    Beispiel:
    Die Datei "meine_tipps.txt" soll neu zum CVS-Modul "CGAL" im Unterverzeichnis "$HOME/cvs-work/CGAL/help" hinzugefügt werden. 

        # Wechseln in das richtige Unterverzeichnis
    cd $HOME/cvs-work/CGAL/help
    # geplantes Hinzufuegen ankuendigen
    cvs add meine_tipps.txt
    # Typische Meldung:
    cvs server: scheduling file `meine_tipps.txt' for addition
    cvs server: use 'cvs commit' to add this file permanently
    # Veroeffentlichen
    cvs commit meine_tipps.txt
    # Typische Meldung:
    RCS file: /share/cvs-repository/CGAL/help/meine_tipps.txt,v
    done
    Checking in unterschrift.tex;
    /share/cvs-repository/CGAL/help/meine_tipps.txt,v <-- meine_tipps.txt
    initial revision: 1.1
    done
    Die Version von "meine_tipps.txt" wird vom CVS-Server automatisch auf 1.1 gesetzt (und im RCS-Format abgespeichert).

    top top

  17. Wie kann ich ein neues Unterverzeichnis zum CVS-Modul hinzufügen?

    Fazit: Die entscheidenden Kommandos sind:

    • cvs add
    • cvs commit
    • cvs commit <Filename(n)>

    Im Detail:
    Wenn es nur um die Erstellung eines neuen Unterverzeichnisses geht, genügt ein CVS-Befehl "add" mit dem Unterverzeichnisnamen. Im Unterschied zum Hinzufügen von Dateien wirkt der CVS-Befehl "add" bei Verzeichnissen sofort, muss also nicht durch "commit" ergänzt werden.

    Beispiel:
    Das neue Unterverzeichnis "polygon" soll neu zum CVS-Modul "CGAL" im Unterverzeichnis "$HOME/cvs-work/CGAL/uebung" hinzugefügt werden. 

        # Wechseln in das richtige Unterverzeichnis
    cd $HOME/cvs-work/CGAL/uebung
    # irgendwie neues Unterverzeichnis anlegen
    mkdir polygon
    # Hinzufuegen des Unterverzeichnisses
    cvs add polygon
    # Typische Meldung:
    Directory /share/cvs-repository/CGAL/uebung/polygon added to the repository

    Normalerweise will man aber gleich auch mehrere Dateien eines neuen Unterverzeichnisses hinzufügen. Dann fügt man - wie oben beschrieben - zunächst das Unterverzeichnis zum CVS-Modul hinzu. Dann wechselt man ins Unterverzeichnis und fügt mit "add" einzelne Dateien zum CVS-Modul hinzu. Diese muss man dann wieder mit "commit" einzeln veröffentlichen (siehe Frage zum Hinzufügen von neuen Dateien).

    Beispiel:
    Das neue Unterverzeichnis "polygon" mit den Dateien "erzeuge_polygon.cpp" und "Makefile" sollen neu zum CVS-Modul "CGAL" im Unterverzeichnis "$HOME/cvs-work/CGAL/uebung" hinzugefügt werden. 

        # Wechseln in das richtige Unterverzeichnis
    cd $HOME/cvs-work/CGAL/uebung
    # Hinzufuegen des Unterverzeichnisses
    cvs add polygon
    # Typische Meldung:
    cvs server: scheduling file `meine_tipps.txt' for addition
    cvs server: use 'cvs commit' to add this file permanently
    # Wechseln ins neue Unterverzeichnis
    cd polygon
    # geplantes Hinzufuegen der 2 Dateien ankuendigen
    cvs add erzeuge_polygon.cpp Makefile
    # Typische Meldung:
    cvs server: scheduling file `erzeuge_polygon.cpp' for addition
    cvs server: scheduling file `Makefile' for addition
    cvs server: use 'cvs commit' to add this file permanently
    # Veroeffentlichen vom C++-File
    cvs commit erzeuge_polygon.cpp
    # Veroeffentlichen vom Makefile
    cvs commit Makefile

    top top

  18. Kann ich Dateien aus dem CVS-Modul löschen oder umbenennen?

    Fazit: Die entscheidenden Kommandos sind:

    • cvs delete bzw. cvs remove
    • cvs add
    • cvs commit
    • cvs commit <Filename(n)>

    Im Detail:
    Im Prinzip ja, doch sollte man sehr vorsichtig vorgehen, damit noch alte Versionen weiterhin ausgecheckt werden können. Die unten angegebene Vorgehensweise setzt voraus, dass diese Datei bereits zum CVS-Modul hinzugefügt worden ist.

    Ausschließlich lokal vorhandene Dateien, die noch zu keinem CVS-Modul gehören, kann man natürlich ohne Weiteres löschen oder umbenennen!

    Datei löschen aus dem CVS-Modul:

    Die Datei wird zunächst aus dem lokalen CVS-Arbeitsverzeichnis gelöscht. Dann wird das Löschen aus dem CVS-Modul angekündigt mit dem CVS-Befehl "remove"/"delete". Danach veröffentlicht man das Löschen mit dem CVS-Befehl "commit".
    Achtung! Alle Versionen der Datei kann man trotzdem noch aus dem CVS-Verzeichnis abrufen, nur gehört die Datei nicht mehr zur aktuellsten Fassung des CVS-Moduls!

    Beispiel: Löschen von "unsinn.cpp" (soll bereits zum CVS-Modul hinzugefuegt worden sein) aus dem CVS-Modul "test" 

        # Wechseln in das lokale Arbeitsverzeichnis fuer das CVS-Modul "test"
    cd $HOME/cvs-work/test
    # irgendwie Loeschen von "unsinn.cpp" aus lokalem Arbeitsverzeichnis
    rm unsinn.cpp
    # angekuendigtes Loeschen von "unsinn.cpp" aus CVS-Modul
    # erst NACH tatsaechlichem Loeschen eingeben!
    cvs remove unsinn.cpp
    # Typische Meldung:
    cvs server: scheduling `unsinn.cpp' for removal
    cvs server: use 'cvs commit' to remove this file permanently
    # Veroeffentlichen des Loeschens
    # unbedingt: Loeschen des Files im CVS-Kommentar erwaehnen!
    cvs commit unsinn.cpp
    # Typische Meldung:
    Removing unsinn.cpp;
    /share/cvs-repository/test/unsinn.cpp,v <-- unsinn.cpp
    new revision: delete; previous revision: 1.1
    done
    # nochmal Logmeldungen ansehen
    cvs log unsinn.cpp
    # Typische Meldung:
    # vgl. Version 1.2 (Status: dead!)
    RCS file: /share/cvs-repository/test/Attic/unsinn.cpp,v
    Working file: unsinn.cpp
    ...
    revision 1.2
    date: 2001/10/29 10:24:23; author: robert; state: dead; lines: +0 -0
    Loeschen der C++-Datei aus CVS-Modul mit "cvs remove unsinn.cpp"
      und "cvs commit unsinn.cpp"
    revision 1.1
    date: 2001/10/29 10:21:57; author: robert; state: Exp;
    neues C++-File zur spaeteren Demonstration des Loeschens

    Datei umbennen im CVS-Modul:

    Das Vorgehen ähnelt stark dem oben beschriebenen Löschen.
    Die Datei wird zunächst im lokalen CVS-Arbeitsverzeichnis umbenannt. Dann wird das Löschen aus dem CVS-Modul mit dem alten Dateinamen und die Aufnahme in das CVS-Modul mit dem neuen Dateinamen angekündigt mit den CVS-Befehlen "remove"/"delete" und "add". Danach veröffentlicht man das Löschen und das Hinzufügen mit dem CVS-Befehl "commit".

    Achtung! Alle bisherigen CVS-Informationen der Datei kann man trotzdem noch mit dem alten Dateinamen aus dem CVS-Verzeichnis abrufen, nur alle neu gemachten Änderungen erfährt man nur mehr über den neuen Dateinamen.

    Beispiel: Umbenennen von Datei "alter_name.txt" (soll bereits zum CVS-Modul hinzugefuegt worden sein) in "neuer_name.txt" im CVS-Modul "test" 

        # Wechseln in das lokale Arbeitsverzeichnis fuer das CVS-Modul "test"
    cd $HOME/cvs-work/test
    # irgendwie Umbenennen von "alter_name.txt" in "neuer_name.txt"
    # im lokalem Arbeitsverzeichnis
    mv alter_name.txt neuer_name.txt
    # angekuendigtes Loeschen von "alter_name.txt" aus CVS-Modul
    # erst NACH tatsaechlichem Umbenennen eingeben!
    cvs remove alter_name.txt
    # angekuendigte Aufnahme von "neuer_name.txt" in das CVS-Modul
    # erst NACH tatsaechlichem Umbenennen eingeben!
    cvs add neuer_name.txt
    # (gemeinsames) Veroeffentlichen des Loeschens und der Aufnahme
    # (auch getrennt voneinander moeglich)
    # unbedingt: Umbenennung des Files im CVS-Kommentar erwaehnen!
    cvs commit alter_name.txt neuer_name.txt

    top top

  19. Kann ich Unterverzeichnisse aus dem CVS-Modul löschen oder umbenennen?

    Fazit: Die entscheidenden Kommandos sind:

    • cvs delete bzw. cvs remove
    • cvs add
    • cvs commit
    • cvs commit <Filename(n)>
    • cvs update -P

    Im Detail:
    Im Prinzip ja, doch sollte man noch vorsichtiger vorgehen, als bei der Frage zum Löschen/Umbenennen von Files im CVS-Modul beschrieben, damit noch alte Versionen weiterhin ausgecheckt werden können. Die unten angegebene Vorgehensweise setzt voraus, dass das Unterverzeichnis bereits zum CVS-Modul hinzugefügt worden ist.

    Ausschließlich lokal vorhandene Unterverzeichnisse, die noch zu keinem CVS-Modul gehören, kann man natürlich ohne Weiteres löschen oder umbenennen!

    Unterverzeichnis löschen aus dem CVS-Modul:

    Zunächst sollte man alle aus dem Unterverzeichnis zum CVS-Modul gehörenden Files wie in Frage zum Löschen/Umbenennen von Files im CVS-Modul beschrieben löschen. Dann wird der Rest der Files aus dem Unterverzeichnis und das Unterverzeichnis selbst im lokalen CVS-Arbeitsverzeichnis gelöscht. Es gibt keinen CVS-Befehl zum Löschen von Unterverzeichnissen aus dem CVS-Modul! Um zu verhindern, dass das nächste Update automatisch das (dann leere) Unterverzeichnis wieder anlegt, verwende man bei Checkout oder Update zusätzlich die Option "-P". Dies verhindert das Anlegen von leeren Unterverzeichnissen. Will man ein (anderes) leeres Unterverzeichnis bei Checkout oder Update angelegt wissen, muss man mindestens ein (Dummy-)File darin aufnehmen, z.B. ein (leeres) File ".keepme".

    Achtung! Alle Versionen aller in CVS im nunmehr gelöschten Unterverzeichnis verwalteten Dateien kann man trotzdem noch aus dem CVS-Verzeichnis abrufen, nur gehört das Unterverzeichnis nicht mehr zur aktuellsten Fassung des CVS-Moduls!

    Beispiel: Löschen vom Unterverzeichnis "save" mit den Files "unsinn.cpp" und "neuer_name.txt" (sollen bereits zum CVS-Modul hinzugefuegt worden sein) aus dem CVS-Modul "test" 

        # Wechseln in das lokale Arbeitsverzeichnis fuer das CVS-Modul "test"
    cd $HOME/cvs-work/test/save
    # irgendwie Loeschen aller zum CVS-Modul gehörenden Dateien
    # im Unterverzeichnis "save"
    rm neuer_name.txt unsinn.cpp
    # angekuendigtes Loeschen dieser Dateien aus CVS-Modul
    # erst NACH tatsaechlichem Loeschen eingeben!
    cvs remove neuer_name.txt unsinn.cpp
    # Veroeffentlichen des Loeschens
    # unbedingt: Loeschen des Files im CVS-Kommentar erwaehnen!
    cvs commit neuer_name.txt unsinn.cpp
    # Update mit Option "-P" loescht leeres Unterverzeichnis "save"
    cd ..
    cvs update -P
    # Update mit Option "-d" erzeugt leeres Unterverzeichnis "save"
    # wieder! Das wuerde bei "cvs update -d -P" nicht passieren!
    cvs update -d

    Unterverzeichnis umbennen im CVS-Modul:

    Das Vorgehen ähnelt stark dem oben beschriebenen Löschen.
    Zunächst werden alle Dateien des alten Unterverzeichnisses in ein neu erstelltes Unterverzeichnis mit dem neuen Namen (für das alte Unterverzeichnis) im lokalen CVS-Arbeitsverzeichnis verschoben. Dann wird das Löschen aller Files aus dem CVS-Modul unter dem alten Unterverzeichnisnamen sowie die Aufnahme aller verschobenen Files mit dem neuen Unterverzeichnisnamen angekündigt mit den CVS-Befehlen "remove"/"delete" und "add". Danach veröffentlicht man das Löschen und das Hinzufügen mit dem CVS-Befehl "commit".
    Achtung! Alle Versionen aller in CVS im nunmehr umbenannten Unterverzeichnis verwalteten Dateien kann man trotzdem noch aus dem CVS-Verzeichnis abrufen unter dem alten Unterverzeichnis, nur gehört das Unterverzeichnis mit dem alten Namen nicht mehr zur aktuellsten Fassung des CVS-Moduls! Die aktuellen Änderungen erfährt man nur mehr im Unterverzeichnis mit dem neuen Namen.

    Beispiel: Umbenennen vom Unterverzeichnis "sicherung" mit den Files "unsinn.cpp" und "neuer_name.txt" (sollen bereits zum CVS-Modul hinzugefuegt worden sein) in den neuen Namen CVS-Modul "save" 

        # Wechseln in das lokale Arbeitsverzeichnis fuer das CVS-Modul "test"
    cd $HOME/cvs-work/test

    # irgendwie Erstellen des neuen Unterverzeichnisses "save"
    # und Hinzufuegen zum CVS-Modul
    mkdir save
    cvs add save

    # einzelnes Verschieben der relevanten Files "unsinn.cpp" und
    # "neuer_name.txt" im das neue Unterverzeichnis "sicherung"
    mv sicherung/unsinn.cpp save
    mv sicherung/neuer_name.txt save

    # angekuendigtes Loeschen der 2 Dateien aus altem Unterverzeichnis
    # "sicherung"
    # erst NACH tatsaechlichem Verschieben eingeben!
    cvs remove sicherung/unsinn.cpp sicherung/neuer_name.txt

    # angekuendigte Aufnahme der 2 verschobenen Dateien zum
    # neuen Unterverzeichnis "save"
    # erst NACH tatsaechlichem Umbenennen eingeben!
    cvs add save/neuer_name.txt save/unsinn.cpp

    # (gemeinsames) Veroeffentlichen des Loeschens und der Aufnahme
    # (auch getrennt voneinander moeglich)
    # unbedingt: Umbenennung der Unterverzeichnisse im CVS-Kommentar erwaehnen!
    cvs commit sicherung/unsinn.cpp sicherung/neuer_name.txt \
               save/neuer_name.txt save/unsinn.cpp

    # Update mit Option "-P" loescht leeres Unterverzeichnis "sicherung"
    cvs update -P

    # Update mit Option "-r" erzeugt leeres Unterverzeichnis "sicherung"
    # wieder! Das wuerde bei "cvs update -d -P" nicht passieren!
    cvs update -d

    top top

  20. Warum muss ich vorher "cvs add" bei Dateien machen, wenn ich nachher sowieso noch "cvs commit" eingeben muss?

    a) Den Befehl "cvs commit" kann man entweder mit einem Filenamen ergänzen (um eine Veröffentlichung und Kommentierung eines Files durchzuführen) oder aber ohne Filenamen aufrufen. In letzterem Fall werden nicht alle lokalen Dateien veröffentlicht (wäre nicht wünschenswert, sonst würden u.U. auch von manchen Editoren automatisch erzeugte Backup-Kopien von Dateien mitveröffentlicht oder noch unfertige Dateien), sondern nur die Dateien, die mit "cvs add" als zur Veröffentlichung geplant eingestuft worden sind bzw. die Files, die schon zum CVS-Modul gehören und sich lokal geändert haben. "cvs add" dient also zur besseren Einstufung für CVS, was durch ein allgemeines "cvs commit" veröffentlicht werden soll und was nicht.

    b) Das Entfernen einer Datei aus dem CVS-Modul geht auch nur durch den Befehl "cvs remove" mit folgendem Dateinamen und einem anschließenden "cvs commit". Das soll (wie beim Hinzufügen auch) ein voreiliges Löschen aus dem CVS-Modul verhindern. Es ist also eine Art Sicherheitsstufe. Dieses "zusätzliche Hindernis" (erst "cvs add" einer Datei vor einem "cvs commit") vor der Veröffentlichung entfällt, sobald die Datei zum CVS-Modul gehört.

    top top

  21. Kann ich CVS von daheim aus so verwenden, dass ich meine Änderungen von daheim aus an den CVS-Server schicken kann?

    Natürlich! CVS ist weltweit zu benutzen (solange der CVS-Server nicht den Zugriff einschränkt).

    Wenn man unter Linux arbeitet, sollte man das CVS-Paket installieren (falls nicht bereits installiert), unter Windows sollte man eine Windows-Version von CVS installieren, vgl. Frage 4 "Gibt es CVS auch unter Windows?". Nach der Installation muss man die installierte CVS-Version konfigurieren, also Environment-Variablen setzen bzw. für WinCVS entsprechende Voreinstellungen (Name des CVS-Servers, Protokoll, Verzeichnis des CVS-Repositories, ...) im Client setzen, vgl. Frage 5 "Was muss ich beim ersten Mal beachten, wenn ich CVS nutzen will?".

    Bevor man aber mit CVS daheim arbeitet und z.B. einen Checkout oder ein (rekursives) Update durchführen will, muss man vorher per Hand eine Internetverbindung (DFÜ-Verbindung) per Modem/ISDN/sonstwie starten (kann eine Einwahl über Uni@Home an die Universität Bayreuth sein oder per Call-by-Call mit einem Internet-Provider oder über einen festen Internet-Provider wie T-Online, AOL, ...). Diese kann man wieder beenden, wenn das Checkout/der Update beendet sind.

    Vorsicht: Bevor man aber die Änderungen veröffentlicht, muss man die Internetverbindung wieder aufbauen.
    CVS kontaktiert häufig den CVS-Server, z.B. auch bei den Kommandos "cvs diff", "cvs log" und "cvs status", so dass dann immer die Internetverbindung wieder hergestellt werden muss.

    top top

  22. Kann man beim ersten Mal nur einen Teil des CVS-Moduls übertragen?

    Das erste Mal werden durch einen Checkout alle Dateien des CVS-Moduls übertragen, so dass u.U. bei einer langsamen Internetverbindung von daheim aus die Übertragung eine zu lange Zeit in Anspruch nimmt. Daher kann ein vorzeitiges Abbrechen wünschenswert sein.

    Versuche unter Linux haben gezeigt, dass man ein Checkout jederzeit mit CTRL-C abbrechen kann. Dann wird die Übertragung der restlichen Dateien nicht mehr durchgeführt. Es kann dann aber später jederzeit nochmals ein Checkout durchgeführt werden, das dann den Rest der Dateien des CVS-Moduls überträgt.

    Unter Windows ist Vergleichbares zu erwarten. Es ist ja gerade die Aufgabe eines Checkouts, den Stand des CVS-Moduls auf den lokalen Rechner zu bringen. Ist der lokale Stand unvollständig, wird er automatisch ergänzt. Hier sind aber Erfahrungen der Übungsteilnehmer willkommen!

    top top

  23. Wie komme ich an alte Versionen?

    Fazit: Die entscheidenden Kommandos sind:

    • cvs log
    • cvs log -s dead -R
    • cvs update -r <Version> -p
    • cvs status
    • cvs update -A

    Im Detail:
    a) Zuerst einmal den leichteren Fall:
    Die Datei ist noch im CVS-Modul und ist nicht mit "cvs remove" und "cvs commit" entfernt worden.
    Zunächst sollte man sich mit "cvs log" anhand der Kommentare zu den Versionen die Version aussuchen, die man abrufen will.

    Beispiel: 

        cd ~/cvs-work/test
    cvs log version.txt
    # typische Ausgabe:
RCS file: /share/cvs-repository/test/version.txt,v
Working file: version.txt
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3; selected revisions: 3
description:
----------------------------
revision 1.3
date: 2001/11/06 13:47:38; author: robert; state: Exp; lines: +2 -1
brandneu statt neu (7. Zeile)
neue Zeile 7b
----------------------------
revision 1.2
date: 2001/10/31 16:39:25; author: robert; state: Exp; lines: +3 -0
2. Version: vgl. File "version_neu.txt.01"
            erzeugt durch die Befehle
              "cp version_neu.txt.01 version.txt"
            und
              "cvs commit version.txt"
----------------------------
revision 1.1
date: 2001/10/31 16:33:44; author: robert; state: Exp;
1. Version: vgl. File "version_alt.txt.01"
=============================================================================
    Man entscheidet sich, die Version 1.1 abzurufen. Will man diese nicht wieder einchecken, sondern ist nur am Inhalt interessiert, kann man diese Version am Bildschirm ausgeben. 
        # Ausgabe am Bildschirm
    cvs update -r1.1 -p version.txt
    # typische Ausgabe:
===================================================================
Checking out version.txt
RCS: /share/cvs-repository/test/version.txt,v
VERS: 1.1
***************
1. Zeile
2. Zeile
3. Zeile
4. Zeile
5. Zeile
6. Zeile
    Alles nach "***************" und vor obigen Leerzeilen gehört zur Version 1.1.

    Mit dem Befehl 

        cvs update -r1.1 -p version.txt > version_start.txt
    ruft man die Version 1.1 ab und lenkt die Ausgabe um in das neu erstellte File "version_start.txt", das die Version 1.1 von "version.txt" enthält.

    In beiden Fällen kann man das File "version.txt" jederzeit ändern und mit der neuesten Version wieder veröffentlichen. Der Abruf der alten Version stört dabei nicht.

    b) Jetzt der schwierigere Fall:
    Die Datei war im CVS-Modul, ist aber mit "cvs remove" und "cvs commit" entfernt worden.
    Zunächst sollte man sich mit "cvs log" und dem Dateinamen die Versionsgeschichte ansehen, um anhand der Kommentare zu den Versionen die Version aussuchen, die man abrufen will (normalerweise die vorletzte, da die letzte die Version ist, die den Zustand "dead" erhalten hat).

    Beispiel: 

        # Hinzufuegen planen und Veroeffentlichen der 1. Version
    cvs add hokus_pokus.txt
    cvs commit hokus_pokus.txt
    # spaeter: Loeschen im lokalen CVS-Arbeitsverzeichnis
    rm hokus_pokus.txt
    # Loeschen planen und bestaetigendes Loeschen aus CVS-Modul
    cvs remove hokus_pokus.txt
    cvs commit hokus_pokus.txt
    # typische Meldung:
Removing hokus_pokus.txt;
/share/cvs-repository/test/hokus_pokus.txt,v <-- hokus_pokus.txt
new revision: delete; previous revision: 1.1
done
    # Log-Informationen abrufbar, obwohl Datei nicht mehr im lokalen
    # CVS-Arbeitsverzeichnis!
    cvs log hokus_pokus.txt
    # typische Meldung:
RCS file: /share/cvs-repository/test/Attic/hokus_pokus.txt,v
Working file: hokus_pokus.txt
head: 1.2
branch:
locks: strict
access list:
symbolic names:
    keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
----------------------------
date: 2001/11/07 14:14:28; author: robert; state: dead; lines: +0 -0
2. Schritt: Entfernen aus CVS-Modul
              rm hokus_pokus.txt
              cvs remove hokus_pokus.txt
----------------------------
revision 1.1
date: 2001/11/07 14:13:49; author: robert; state: Exp;
File zum Ausprobieren von Aufnahme, Loeschen und Wiederaufnahme in
  CVS-Modul
1. Schritt: Aufnahme mit "cvs add" und "cvs commit"
=============================================================================
    Es fällt auf, dass der Zustand in Version 1.2 als "dead" gekennzeichnet ist und dass das RCS-File im Unterverzeichnis "Attic" am CVS-Server im zum Modul passenden Unterverzeichnis des CVS-Repositories gelandet ist. Jedes "cvs update" ignoriert daher diese Datei und erstellt es nicht mehr neu!

    Eine Wiederaufnahme kann wie prinzipiell wie folgt erfolgen:
    Zuerst die letzte Version ermitteln vor der Version, die den Zustand "dead" hat (normalerweise: die vorletzte). Diese mit "cvs update" und der Option "-rVersionsnummer" abrufen, das File aber sofort temporär umbenennen. Dann ein sog. "sticky tag" löschen (also die Information, dass der Update eine alte Version abgerufen hat) und mit "cvs add" wieder aufnehmen. Erst dann das File wieder zurück umbenennen und es mit "cvs commit" wieder veröffentlichen.

    detailliertes Vorgehen mit vielen Status-Abfragen: 

        # Log-Informationen abrufen
    cvs log hokus_pokus.txt

    # --> nach letzter Version suchen, die noch nicht den Zustand "dead"
    # hat (normalerweise die vorletzte; hier: Version 1.1 mit
    # Zustand "Exp")

    cvs update -r1.1 hokus_pokus.txt

    # Log-Informationen zeigen noch Zustand "dead" und RCS-File im
    # Attic-Unterverzeichnis
    cvs log hokus_pokus.txt

    # Statusanfrage meldet Zustand "Up-to-date"
    cvs status hokus_pokus.txt

    # typische Ausgabe:

===================================================================
File: hokus_pokus.txt Status: Up-to-date

   Working revision: 1.1
   Repository revision: 1.1 /share/cvs-repository/test/Attic/hokus_pokus.txt,v
   Sticky Tag: 1.1
   Sticky Date: (none)
   Sticky Options: (none)

    # kurzzeitiges (wichtiges) Umbenennen
    mv hokus_pokus.txt hokus_pokus.txt.temp

    # Statusanfrage meldet Zustand "Needs Checkout"
    cvs status hokus_pokus.txt

    # typische Ausgabe:

===================================================================
File: no file hokus_pokus.txt Status: Needs Checkout

   Working revision: 1.1
   Repository revision: 1.1 /share/cvs-repository/test/Attic/hokus_pokus.txt,v
   Sticky Tag: 1.1
   Sticky Date: (none)
   Sticky Options: (none)

    # Zuruecksetzen der "sticky flags" durch Option "-A"
    # noetig, da CVS denkt, dass die Version 1.2 noch aktuell ist
    # (spaetestens jetzt wuerde ohne vorangegangenes Umbenennen
    # die Datei von CVS geloescht werden)

    cvs update -A hokus_pokus.txt

    # typische Ausgabe:
cvs server: warning: hokus_pokus.txt is not (any longer) pertinent

    # Statusanfrage meldet Zustand "Up-to-date", Version ist 1.2!
    # Das "sticky tag" mit Wert 1.1 tritt nicht mehr auf!
    cvs status hokus_pokus.txt

    # typische Ausgabe:
===================================================================
File: no file hokus_pokus.txt Status: Up-to-date

   Working revision: No entry for hokus_pokus.txt
   Repository revision: 1.2 /share/cvs-repository/test/Attic/hokus_pokus.txt,v

    # Wiederhinzufuegen der Datei (die lokal noch "hokus_pokus.txt.temp" heisst)
    cvs add hokus_pokus.txt

    # typische Ausgabe:
    cvs server: re-adding file hokus_pokus.txt (in place of dead revision 1.2)
    cvs server: use 'cvs commit' to add this file permanently

    # Statusanfrage meldet Zustand "Entry Invalid", Version ist aber 1.2!
    cvs status hokus_pokus.txt

    # typische Ausgabe:

cvs server: warning: new-born hokus_pokus.txt has disappeared
===================================================================
File: no file hokus_pokus.txt Status: Entry Invalid

   Working revision: New file!
   Repository revision: 1.2 /share/cvs-repository/test/Attic/hokus_pokus.txt,v
   Sticky Tag: (none)
   Sticky Date: (none)
   Sticky Options: (none)

    # Umbenennen:
    mv hokus_pokus.txt.temp hokus_pokus.txt

    # Statusanfrage meldet Zustand "Locally Added", Version ist aber 1.2!
    cvs status hokus_pokus.txt

    # typische Ausgabe:
===================================================================
File: hokus_pokus.txt Status: Locally Added

   Working revision: New file!
   Repository revision: 1.2 /share/cvs-repository/test/Attic/hokus_pokus.txt,v
   Sticky Tag: (none)
   Sticky Date: (none)
   Sticky Options: (none)

    # Veroeffentlichen als neue Version 1.3
    cvs commit hokus_pokus.txt

    # typische Ausgabe:
Checking in hokus_pokus.txt;
/share/cvs-repository/test/hokus_pokus.txt,v <-- hokus_pokus.txt
new revision: 1.1; previous revision: 1.2
done

    # Statusanfrage meldet Zustand "Up-to-date", Version ist 1.3
    # und das RCS-File ist aus dem Untervrzeichnis "Attic" in das
    # uebergeordnete Verzeichnis verschoben worden!
    cvs status hokus_pokus.txt

    # typische Ausgabe:
===================================================================
File: hokus_pokus.txt Status: Up-to-date

   Working revision: 1.3
   Repository revision: 1.3 /share/cvs-repository/test/hokus_pokus.txt,v
   Sticky Tag: (none)
   Sticky Date: (none)
   Sticky Options: (none)

    Kennt man gar nicht mehr den Dateinamen, hilft auch kein "cvs update" mehr, da diese Datei nicht mehr zum CVS-Modul gehört. Dann kann man 

        # Abfrage nach allen Dateien im CVS-Modul, die den Zustand "dead" haben
    # (Option "-s dead"), Ausgabe nur der RCS-Filenamen (Option "-R")
    cvs log -s dead -R

    # typische Ausgabe:
    # leider werden alle Dateien (auch die mit Zustand "Exp") ausgegeben !?!

cvs server: Logging .
/share/cvs-repository/test/Attic/Brandneu.txt,v
/share/cvs-repository/test/CgalOnWin.htm,v
/share/cvs-repository/test/CgalOnWinCygWin.htm,v
/share/cvs-repository/test/Attic/Test.txt,v
/share/cvs-repository/test/Test_r1.6.txt,v
/share/cvs-repository/test/alter_name.txt,v
/share/cvs-repository/test/Attic/hokus_pokus.txt,v
/share/cvs-repository/test/Attic/neuer_name.txt,v
/share/cvs-repository/test/test.html,v
...
    Aus dieser Liste schaut man sich alle an, deren RCS-Files im Unterverzeichnis "Attic" gelandet sind. Das sind dann die aus dem CVS-Modul gelöschten Files (hier: "Brandneu.txt", "Test.txt", "hokus_pokus.txt", "neuer_name.txt"). So erfährt man die Namen der bereits gelöschten Dateien aus dem CVS-Modul.

    Eine Wiederaufnahme kann man auch am CVS-Server (mit Root-Rechten) erreichen (Achtung: u.U. nicht ungefährlich!).

    Beispiel: 

        cd /share/cvs-repository/test

    # Verschieben aus Unterverzeichnis "Attic" in Modulverzeichnis
    # (zur Demonstration des Unterschieds wird hier kopiert)
    cp Attic/hokus_pokus.txt,v .

    # Ändern des Zustands "dead" der letzten Version im Editor
    # in den Zustand "Exp" (Log-Meldung mit dem Löschen bleibt
    # ehalten)
    vi hokus_pokus.txt,v
      ...

    diff hokus_pokus.txt,v Attic

    # typische Ausgabe:
    13c13
    < date 2003.03.18.10.49.52; author robert; state Exp;
    ---
    > date 2003.03.18.10.49.52; author robert; state dead;

    # gefahrloses Löschen möglich
    # (zur Demonstration des Unterschieds wird das erst jetzt gemacht)
    rm Attic/hokus_pokus.txt,v
    Ein "cvs update hokus_pokus.txt" auf Client-Seite lässt das File wieder erscheinen (die Version, die vorher zum Löschen entstanden ist, ist jetzt die aktuellste Version).

    top top

  24. Was muss ich tun, damit ich später einmal eine ältere Version meines Moduls/Unterverzeichnisses abrufen kann?

    Diese Frage ist etwas weitergehend als die Frage zu den alten Versionen. Solange man nur an alte Versionen einiger weniger Dateien herankommen muss, kann man diese wie in der Antwort zur Frage zu den alten Versionen abrufen. Es gibt allerdings auch einen eleganteren Weg, der auch für sehr viele Dateien funktioniert. Dieser setzt allerdings voraus, dass man vor dem Eintreten dieses Wunsches symbolische Bezeichnungen für eine Version aller Dateien des Programmpakets gesetzt hat. Man erreicht dies durch das CVS-Kommando "rtag" (nicht zu verwechseln mit dem CVS-Kommando "tag"!). Dieses gibt den aktuellen Versionen aller Dateien eines CVS-Moduls oder eines Unterverzeichnisses eine symbolische Versionsbezeichnung. Diese kann man sich, nebenbei bemerkt, auch besser merken, als die evtl. unterschiedlichen Versionsnummern verschiedener (vieler) Dateien.
    Danach kann man ggf. mit dem CVS-Kommando "export" eine ältere Version eines CVS-Moduls (oder eines Unterverzeichnisses) abrufen und (normalerweise) in ein neues Unterverzeichnis abspeichern.

    Fazit: Die entscheidenden Kommandos sind:

    • cvs status -v
    • cvs rtag
    • cvs update -r <Version> -p
    • cvs export -r <Version> -d <Unterverzeichnis>

    Beispiel: 

        cd ~/cvs-work/test
    cvs update -dP
    cd work
    # Das File hat noch keine symbolische Versionsnummer
    cvs status -v File.txt
    # typische Ausgabe:
    ===================================================================
File: File.txt Status: Up-to-date
   Working revision: 1.1
   Repository revision: 1.1 /share/cvs-repository/test/work/File.txt,v
   Sticky Tag: (none)
   Sticky Date: (none)
   Sticky Options: (none)
   Existing Tags:
        No Tags Exist

    # als Startversion "start" kennzeichnen (nur im Unterverzeichnis work
    # vom Modul "test"
    cvs rtag start test/work

    # Typische Meldung:
    cvs server: Tagging test/work

    # File hat symbolische Versionsnummer "start", die auf Version 1.1
    # verweist
    cvs status -v File.txt

    # typische Ausgabe:
    ===================================================================
    File: File.txt Status: Up-to-date

       Working revision: 1.1
       Repository revision: 1.1 /share/cvs-repository/test/work/File.txt,v
       Sticky Tag: (none)
       Sticky Date: (none)
       Sticky Options: (none)

       Existing Tags:
            start (revision: 1.1)

    # in der Zwischenzeit neue Versionen erzeugen
    # (Version 1.4 fuer "File.txt" und 1.2 fuer "Weiteres_File.txt"
    ...

    # momentanen Stand des Unterverzeichnisses als Version "version-1"
    # kennzeichnen
    cvs rtag version-1 test/work

    # Typische Meldung:
    cvs server: Tagging test/work

    # File "File.txt" hat symbolische Versionsnummer "version-1",
    # die auf Version 1.4 verweist
    cvs status -v File.txt

    # typische Ausgabe:
    ===================================================================
    File: File.txt Status: Up-to-date

       Working revision: 1.4
       Repository revision: 1.4 /share/cvs-repository/test/work/File.txt,v
       Sticky Tag: (none)
       Sticky Date: (none)
       Sticky Options: (none)

       Existing Tags:
            version-1 (revision: 1.4)
            start (revision: 1.1)

    # File "Weiteres_File.txt" hat symbolische Versionsnummer "version-1",
    # die auf Version 1.2 verweist
    cvs status -v Weiteres_File.txt

    # typische Ausgabe:
    ===================================================================
    File: File.txt Status: Up-to-date

       Working revision: 1.2
       Repository revision: 1.2 /share/cvs-repository/test/work/Weiteres_File.txt,v
       Sticky Tag: (none)
       Sticky Date: (none)
       Sticky Options: (none)

       Existing Tags:
            version-1 (revision: 1.2)
            start (revision: 1.1)
    Der Anfangsstand ist also der symbolischen Version "start" zugeordnet, die 1. Version der symbolischen Version "version-1". Muss man auf alte Versionen zugreifen, kann man für einzelne Files durch "cvs update" mit dem symbolischen Versionsnamen alte Versionen abrufen.

    Beispiel: 

        # das File "File_start.txt" enthält die Version "start"
    # (also die Version 1.1) vom File "File.txt";
    # das aktuelle lokale File "File.txt" wird nicht überschrieben
    cvs update -r start -p File.txt > File_start.txt

    # typische Ausgabe:
    ===================================================================
    Checking out File.txt
    RCS: /share/cvs-repository/test/work/File.txt,v
    VERS: 1.1
    ***************

    # das File "File_v1.txt" enthält die Version "version-1"
    # (also die Version 1.4) vom File "File.txt";
    cvs update -r version-1 -p File.txt > File_v1.txt

    # typische Ausgabe:
    ===================================================================
    Checking out File.txt
    RCS: /share/cvs-repository/test/work/File.txt,v
    VERS: 1.4
    ***************

    # das File "Weiteres_File_v1.txt" enthält die Version "version-1"
    # (also die Version 1.4) vom File "Weiteres_File.txt";
    cvs update -r version-1 -p Weiteres_File.txt > Weiteres_File_v1.txt

    # typische Ausgabe:
    ===================================================================
    Checking out Weiteres_File.txt
    RCS: /share/cvs-repository/test/work/Weiteres_File.txt,v
    VERS: 1.2
    ***************

    Man kann aber auch durch "cvs export" in ein ggf. neu zu erstellendes Unterverzeichnis alle Dateien des Moduls oder eines Unterverzeichnisses mit derselben symbolischen Versionsnummer abrufen.

    Beispiel: 

        cd $HOME/cvs-work/test/work

    # Abspeichern der Version "start" im Unterverzeichnis "rel-0"
    cvs export -r start -d rel-0 test/work

    # Typische Meldung:
    cvs export: Updating rel-0
    U rel-0/Altes_File.txt
    U rel-0/File.txt
    U rel-0/Neues_Tag.txt
    U rel-0/Neues_Tag2.txt
    U rel-0/Weiteres_File.txt

    # Abspeichern der Version "version-1" im Unterverzeichnis "rel-1"
    cvs export -r start -d version-1 test/work

    # Typische Meldung:
    cvs export: Updating rel-1
    U rel-1/Altes_File.txt
    U rel-1/File.txt
    U rel-1/Neues_Tag.txt
    U rel-1/Neues_Tag2.txt
    U rel-1/Weiteres_File.txt

    top top

  25. Was passiert, wenn man eine Datei aus dem Modul entfernt und eine ganz andere mit demselben Namen in das Modul einfügen will?

    Fazit: Die entscheidenden Kommandos sind:

    • cvs log
    • cvs status
    • cvs add
    • cvs commit

    Im Detail:
    Das ganze geht, ist aber nicht ganz unproblematisch, weil zwei verschiedene Sachen unter einem Filenamen verwaltet werden, was bei verschiedenen Versionen zur Verwirrung führen kann.

    Beispiel: Das File "uralt.txt" wurde zum CVS-Modul hinzugefügt, dann aber gelöscht. 

       cvs add uralt.txt
   cvs commit uralt.txt
   cvs stat uralt.txt
   # typische Ausgabe:
===================================================================
File: uralt.txt Status: Up-to-date
   Working revision: 1.1
   Repository revision: 1.1 /share/cvs-repository/test/uralt.txt,v
   Sticky Tag: (none)
   Sticky Date: (none)
   Sticky Options: (none)
   cvs log uralt.txt

   # typische Ausgabe:

RCS file: /share/cvs-repository/test/uralt.txt,v
Working file: uralt.txt
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
----------------------------
revision 1.1
date: 2002/05/21 08:48:37; author: robert; state: Exp;
Testfile fuer Loeschen und Wiedereinchecken eines anderen Files unter
demselben Namen
=============================================================================

   # Loeschen des Files lokal
   rm uralt.txt

   # Loeschen des Files im CVS-Modul
   cvs delete uralt.txt
   cvs commit uralt.txt

   # typische Ausgabe:

Removing uralt.txt;
/share/cvs-repository/test/uralt.txt,v <-- uralt.txt
new revision: delete; previous revision: 1.1
done

   # probeweise "cvs log":
   cvs log uralt.txt

   # typische Ausgabe, siehe RCS file und Unterverzeichnis "Attic"
   # sowie "state" (Zustand) "dead" in Version 1.2

RCS file: /share/cvs-repository/test/Attic/uralt.txt,v
Working file: uralt.txt
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
----------------------------
revision 1.2
date: 2002/05/21 08:54:31; author: robert; state: dead; lines: +0 -0
Loeschen des Files aus dem CVS-Modul mit
  rm uralt.txt
  cvs delete uralt.txt
  cvs commit uralt.txt
----------------------------
revision 1.1
date: 2002/05/21 08:48:37; author: robert; state: Exp;
...

   # probeweise "cvs stat":
   cvs stat uralt.txt

   # typische Ausgabe, siehe Filename und Unterverzeichnis "Attic"
   # sowie "state" (Zustand) "dead" in Version 1.2

===================================================================
File: no file uralt.txt Status: Up-to-date

   Working revision: No entry for uralt.txt
   Repository revision: 1.2 /share/cvs-repository/test/Attic/uralt.txt,v

   # liefert nicht das File "uralt.txt" in Version 1.2, sondern gar nichts!
   cvs update

   # auch das geht nicht ...
   cvs update uralt.txt
    Fügt man jetzt versehentlich ein neues File unter dem alten Dateinamen hinzu, der noch dazu als gelöscht markiert ist im CVS-Modul, geht das prinzipiell. Allerdings sollte man das besser vermeiden, es kommt nur ein Hinweis auf Wiederaufnahme eines alten Files ("re-adding") und die tote Version ("dead revision").

    Beispiel: 

       mv neues_file.txt uralt.txt

   # scheitert, da "uralt.txt" aus CVS-Modul geloescht wurde
   cvs commit uralt.txt

   cvs add uralt.txt

   # typische Ausgabe, man erkennt an "re-adding" und "dead revision"
   # schon das Problem:
   cvs server: re-adding file uralt.txt (in place of dead revision 1.2)
   cvs server: use 'cvs commit' to add this file permanently

   # bei "cvs log" kommt wieder der Hinweise auf tote Version 1.2
   cvs log uralt.txt

    top top

  26. Wie kann man selbst auf einem Linux-Rechner einen CVS-Server etablieren?

    Erklärung fehlt noch ...

    top top

  27. Wie kann man ein binäres File mit CVS verwalten?

    Fazit: Die entscheidenden Kommandos sind:

    • cvs add -k 'b'
    • cvs log
    • cvs status

    Im Detail:
    Es gibt zwei Wege: Erstens die Methode, alles selbst zu regeln (ohne des CVS-Administrator) und zweitens die Methode, den CVS-Administrator mit einzuschalten.

    a) alles selbst regeln
    In diesem Fall muss man beim Hinzufügen der Datei zum Repositorymodul eine Option mit angeben (genauer: eine RCS-Option übergeben), die das File als Binärfile kennzeichnet.

    Beispiel: 

       cvs add -k 'b' binaer_file.txt.gz
   # oder alternativ:
   # cvs add -kb binaer_file.txt.gz
   # Kontrolle mit "cvs status": Sticky Option "-kb" weist auf Binaerfile hin
   cvs status binaer_file.txt.gz
     ===================================================================
     File: binaer_file.txt.gz Status: Locally Added
        Working revision: New file!
        Repository revision: No revision control file
        Sticky Tag: (none)
        Sticky Date: (none)
        Sticky Options: -kb
   # danach Arbeiten wie ueblich
   cvs commit binaer_file.txt.gz
   # Kontrolle mit "cvs log":
   # "keyword substitution" auf "b" weist auf Binaerfile hin
   cvs log binaer_file.txt.gz
     ===================================================================
     RCS file: /share/cvs-repository/test/binaer_file.txt.gz,v
     Working file: binaer_file.txt.gz
     head: 1.1
     branch:
     locks: strict
     access list:
     symbolic names:
     keyword substitution: b
     total revisions: 1; selected revisions: 1
     ...

    b) mit dem CVS-Administrator prinzipiell regeln
    Der CVS-Administrator kann prinzipiell Dateien mit vorgegebener Endung zu Binärfiles für alle CVS-Benutzer gehen. Er geht dazu in das Unterverzeichnis "CVSROOT" und ergänzt in der Datei "cvswrappers" die Zeile: 

       *.gz -k 'b'

    Hinweise/Hilfe:
    Man vergleiche die Manualseite zu den RCS-Kommandos (auf denen CVS basiert!) "rcs" und "co", Stichwort "keyword substitution" und Option "-kb" sowie die Online-Hilfe zu CVS selbst, hier: "cvs --help add" (unter "rcs-kflag" versteht man die Option "-k" von "rcs" bzw. "co").

    top top

  28. Wie kann Files, die mit RCS verwaltet werden, auf CVS-Verwaltung umstellen?

    Im Unterverzeichnis "RCS" bzw. im aktuellen Verzeichnis befinden sich die RCS-Files mit der Endung ",v". Diese werden einfach in das entsprechende CVS-Verzeichnis am Server (erfordert natürlich im Normalfall Root-Rechte am Server) kopiert. Beim nächsten Befehl "cvs update -d" im passenden lokalen CVS-Arbeitsverzeichnis erscheinen die vorher mit RCS verwalteten Files automatisch (ohne RCS-Informationen).

    Beispiel:

    Die mit RCS-Files verwalteten Files 

        programm.c
    Readme.txt
    befinden sich im Unterverzeichnis "work/proj_1" auf dem Rechner "btrzxi.rz.uni-bayreuth.de", die RCS-Files selbst 
        programm.c,v
    Readme.txt,v
    im Unterverzeichnis "work/proj_1/RCS" (auf demselben Rechner).

    Das Verzeichnis für das CVS-Repository sei auf dem Rechner "btcipmatx15.cip.uni-bayreuth.de" im Directory "/share/cvs-repository" im Directory. Die RCS-verwalteten Files sollen vom Arbeitsrechner "btcipmatx9.cip.uni-bayreuth.de" aus in das Modul "software" unter dem Unterverzeichnis "proj_1" abgelegt werden. Das lokale CVS-Arbeitsverzeichnis am Rechner "btcipmatx9.cip.uni-bayreuth.de" sei unter dem Verzeichnis "~/cvs-work".

    Beispiel: Nötige Kommandos sind: 

        # auf dem Rechner btcipmatx9.cip.uni-bayreuth.de
    cd ~/cvs-work/software

    # erstmal neues Unterverzeichnis unterhalb der Arbeitskopie des Moduls
    # "software" anlegen
    mkdir proj_1

    # neues Unterverzeichnis zum Modul "software" hinzufuegen
    cvs add proj_1

    # auf dem Rechner btrzxi.rz.uni-bayreuth.de einloggen
    ssh btrzxi.rz.uni-bayreuth.de

    # Wechseln ins RCS-interne Unterverzeichnis
    cd ~/work/proj_1/RCS

    # Kopieren mit Secure Copy (Root-Rechte auf CVS-Server erforderlich)
    # der RCS-Files "programm.c,v" und "Readme.txt,v"
    # in das Unterverzeichnis "software/proj_1"
    scp *,v \
      root@btcipmatx15.cip.uni-bayreuth.de:/share/cvs-repository/software/proj_1

    # Ausloggen am Rechner btrzxi.rz.uni-bayreuth.de
    exit

    # auf dem Rechner btcipmatx9.cip.uni-bayreuth.de
    cd ~/cvs-work/software/proj_1

    # es erscheinen die frueher mit RCS verwalteten Files
    # "programm.c" und "Readme.txt"
    cvs update

    Sollen die Files unter CVS einen neuen Filenamen bekommen, z.B.

    "prog.c" statt "programm.c" und
    "Liesmich.txt" statt "Readme.txt",
    braucht man nur den SCP-Befehl ändern (also die Filenamen der RCS-Files, die im CVS-Repository gespeichert werden).

    Beispiel: Nötige Kommandos sind: 

        # Kopieren mit Secure Copy (Root-Rechte auf CVS-Server erforderlich)
    # der RCS-Files "programm.c,v" und "Readme.txt,v"
    # in das Unterverzeichnis "software/proj_1" mit Umbenennen des Namens
    scp programm.c,v \
      root@btcipmatx15.cip.uni-bayreuth.de:/share/cvs-repository/software/proj_1/prog.c
    scp Readme.txt,v \
      root@btcipmatx15.cip.uni-bayreuth.de:/share/cvs-repository/software/proj_1/Liesmich.txt

    # auf dem Rechner btcipmatx9.cip.uni-bayreuth.de
    # erscheinen dann mit denselben Schritten wie vorher
    # die frueher mit RCS verwalteten Files
    # "programm.c" und "Readme.txt" als Dateien "prog.c" und "Liesmich.txt"
    cvs update

    War das mit RCS vorher gepflegte File (leider) gelockt (z.B. durch ein RCS-Kommando wie "co -l address.html"), gibt es Probleme bei späteren Veränderungen.

    Beispiel: Das RCS-File "address.html,v" mit Version 1.4 wurde im gelockten Zustand in das CVS-Verzeichnis aufgenommen. Vor Änderungen muss man zuerst mit "cvs admin -u" den Lock-Zustand aufheben. 

        # Auffällig bei der unten stehenden Ausgabe ist die Zeile, die mit "locks"
    # beginnt und nicht einfach nur "locks: strict" enthält,
    # sondern die von User "btm543" gelockte Version 1.4 zeigt.
    # Zudem steht in der Zeile nach "description:" und dem Trennstrich
    # nicht einfach nur "revision 1.4", sondern der Hinweis
    # "revision 1.4    locked by: btm543;".

    cvs log -r address.html

    # typische Ausgabe:
    RCS file: /share/cvs-repository/test/work/address.html,v
    Working file: address.html
    head: 1.4
    branch:
    locks: strict
            btm543: 1.4
    access list:
    symbolic names:
    keyword substitution: kv
    total revisions: 4; selected revisions: 1
    description:
    Adressen der Bayreuther Mitglieder
    ----------------------------
    revision 1.4 locked by: btm543;
    date: 1997/04/30 17:24:11; author: btm543; state: Exp; lines: +3 -3
    ...

    # eine Veröffentlichung einer Veränderung
    # scheitert im lock-Zustand
    vi address.html
      ...
    cvs commit address.html

    # typische Ausgabe:
    cvs [server aborted]: Revision 1.4 is already locked by btm543
    cvs commit: saving log message in /tmp/cvs66N4ES

    # Lock-Zustand von Version 1.4 aufheben
    cvs admin -u1.4 address.html

    # typische Ausgabe:
    RCS file: /share/cvs-repository/test/work/address.html,v
    1.4 unlocked
    done

    # "cvs log" zeigt normale Ausgaben (kein Lock-Zustand mehr)
    cvs log -r address.html

    # typische Ausgabe:
    RCS file: /share/cvs-repository/test/work/address.html,v
    Working file: address.html
    head: 1.4
    branch:
    locks: strict
    access list:
    symbolic names:
    keyword substitution: kv
    total revisions: 4; selected revisions: 1
    description:
    Adressen der Bayreuther Mitglieder
    ----------------------------
    revision 1.4
    date: 1997/04/30 17:24:11; author: btm543; state: Exp; lines: +3 -3
    ...

    # "cvs commit" gelingt jetzt
    cvs commit address.html

    Am CVS-Server hätte man mit Root-Rechten (Achtung: u.U. nicht ungefährlich!) die Datei "address.html,v" per Hand ändern können (vgl. das Beispiel 
        cd /share/cvs-repository/test/work
    # diff <ungelockte Version> <gelockte Version>

    # typische Ausgabe:
    4c4,5
    < locks; strict;
    ---
    > locks
    > btm543:1.4; strict;
    am CVS-Server) und hätte dasselbe erreicht.

    top top

  29. Wie kann man Files für die Utilities "patch" bzw. "ed" aus CVS erzeugen?

    Beispiel: Das File "Test_Patch.txt" soll die Version 1.3 besitzen. Die Tests werden in einem temporären Unterverzeichnis "temp" durchgeführt. 

        # erzeuge temporaeres Verzeichnis
    mkdir temp
    # kopiere Version 1.2 und 1.3 in dieses Verzeichnis
    cvs update -r1.2 -p Test_Patch.txt > temp/Test_Patch_v2.txt
    cp Test_Patch.txt temp
    # erzeuge ein Differenzenfile fuer "patch" durch Option "-c"
    # (steht für "context diff")
    cvs diff -c -r 1.2 Test_Patch.txt > temp/patch_2.txt
    # wende das Differenzenfile mit "patch" an und erzeuge
    # aus der Version 1.3 die Version 1.2 (-R = reverse patch)
    # (das File "Test_Patch.txt" wird modifiziert
    # und enthält dann die Version 1.2)
    cd temp
    patch -R Test_Patch.txt patch_2.txt
    # typische Ausgabe:
    patching file Test_Patch.txt
    # es gibt keinen Unterschied zwischen dem gepatchten File
    # und der Version 1.2 aus dem CVS-Modul
    # (keine Ausgabe --> Files sind gleich)
    diff Test_Patch_v2.txt Test_Patch.txt

    In Newsgruppen wird darauf hingewiesen, dass man Differenzenfiles für ganze Modulverzeichnisse besser mit dem CVS-Kommand "cvs rdiff" bzw. "cvs patch" (anderer Name) erzeugt.
    Ein Teilnehmer einer Newsgruppe wies darauf hin, dass "cvs diff -NR" bzw. "cvs diff -NauR" rekursiv (durch Option "-R") für Files aus Unterverzeichnissen ein Patchfile erzeugt (durch die Option "-N" sogar für Files, die mit "cvs add/remove" sonst ausgeschlossen sind). Andere betonten, dass so ein Differenzenfile keine Verzeichnisstruktur speichert und daher nicht für "patch" geeignet ist.
    Noch keine Beurteilung meinerseits ... .

    Beispiel: ähnlich mit Differenzenfile für "ed" 

        # gehe in uebergeordnete Verzeichnis von temp
    cd ..

    # erzeuge ein Differenzenfile für "ed" durch Option
    # "-e" ("-e" steht für "ed"
    # und ist eine Option von "diff", die man in
    # "rcsdiff" und "cvs diff" verwenden kann
    # Die Ausgabe erfolgt im Shellfenster.
    cvs diff -e -r 1.2 Test_Patch.txt

    # typische Ausgabe:
    Index: Test_Patch.txt
    ===================================================================
    RCS file: /share/cvs-repository/test/Test_Patch.txt,v
    retrieving revision 1.2
    retrieving revision 1.3
    diff -e -r1.2 -r1.3
    6a
    6. Zeile
    .
    1c
    0. Zeile
    .
    # speichert man die Zeilen NACH der Zeile "diff -e ..."
    # in eine Datei "ed_2.txt" und hängt noch eine letzte Zeile
    # mit "w" an, kann man diese Kommandos für einen ed-Aufruf
    # verwenden.

    cat << EOF > temp/ed_2.txt
    > 6a
    > 6. Zeile
    > .
    > 1c
    > 0. Zeile
    > .
    > w
    > EOF

    cd temp

    # wende das Differenzenfile mit "ed" an und erzeuge
    # aus der Version 1.2 die Version 1.3
    # (das File "Test_Patch_v2.txt" wird modifiziert
    # und enthält dann die Version 1.3)
    cd temp
    cat ed_2.txt | ed Test_Patch_v2.txt

    # typische Ausgabe:
    # (Dateigröße)
    74
    83

    # es gibt keinen Unterschied zwischen dem veränderten File
    # und der Version 1.3 aus dem CVS-Modul
    # (keine Ausgabe --> Files sind gleich)
    diff Test_Patch_v2.txt ../Test_Patch.txt

    top top

  30. Wie kann man ein unbeabsichtigtes Warten auf einen behobenen Lock-Zustand am CVS-Server beenden?

    Sollte bei geplanten Veränderungen des CVS-Moduls (z.B. durch ein "cvs commit" für ein File des Moduls) die Hinweismeldung 

        # typische Ausgabe eines CVS-Kommandos, das die Probleme verursachte
    ...
    CVS locks may need cleaning up.
    ...
    # typische Ausgabe (wiederholt sich alle 30 Sekunden):
    cvs server: [12:45:22] waiting for root's lock in /share/cvs-repository/test/work
    cvs server: [12:45:52] waiting for root's lock in /share/cvs-repository/test/work
    ...
    # Eingabe von CTRL-C unterbricht das Warten
    # typische Ausgabe:
    cvs [commit aborted]: received interrupt signal
    erscheinen, kann es sein, dass unbeabsichtigt ein File mit einem Namen vergleichbar zu 
        #cvs.rfl.btcipmatx15.cip.uni-bayreuth.de.4623
    am CVS-Server durch ein CVS-Problem entstanden ist. Dieses kennzeichnet einen Lock-Zustand des Servers. Sollte dies nicht beabsichtigt worden sein, kann man dieses File am CVS-Server (mit Root-Rechten) löschen. Erst dann klappt z.B. ein Kommando wie "cvs commit" wieder.

    top top

  31. Wer setzt CVS ein?

    CVS wird in der Public Domain-Entwicklerszene sehr häufig eingesetzt, da viele Programme weltweit entwickelt werden und es ist daher immer ein Problem ist, sich als Entwickler auf den neuesten Stand des Projekts zu bringen.

    Viele Public Domain-Projekte (vor allem im Linux-Umfeld) speichern den aktuellen Stand ihrer Projekte unter dem SourceForge-Server, der Speicherplatz und den Webauftritt dieser Projekte unterstützt. Dies geschieht mit Hilfe von CVS und CVSweb. Zur weiteren Information zu SourceForge:

    -> Informationen über SourceForge selbst
    -> Software, die SourceForge einsetzt
    -> cvsweb (CGI-Skript zum Einbinden von CVS-Repositories im WWW-Server)
    einige ausgesuchte Projekte unter SourceForge:
    -> MiKTeX (Windows-Distribution von TeX/LaTeX)
    -> Mesa3D (Public Domain-Clone von OpenGL, eine 3D-Grafiklibrary, die weitgehend zu OpenGL kompatibel ist)
    -> AFPL Ghostscript (PostScript-Viewer)
    -> CvsGui-Projekt bei Sourceforge (high-end GUIs zu CVS, inkl. WinCvs, gCvs, ...)
    -> GCW (GCC for Windows, maximale Unterstützung von und Binärkompatibilität zu Microsoft Visual C++ Source Code)

    einige ausgesuchte Software-Projekte, die einen Download per CVS anbieten:

    -> Apache (freier WWW-Server)
    -> Infos zum Download der neuesten Entwicklerversion

    -> CVS (CVS-Software selbst)
    -> Infos zum Download der neuesten Entwicklerversion

    -> cvsweb (CGI-Skript zum Einbinden von CVS-Repositories in einem WWW-Server)
    -> Infos zum Download der neuesten Entwicklerversion

    -> Cygwin (Unix-Umgebung und Shell unter Windows)
    -> Infos zum Download der neuesten Entwicklerversion

    -> GCC (Gnu Compiler Collection)
    -> Infos zum Download der neuesten Entwicklerversion

    -> XFree86 (Open Source-Version von X Window unter Unix, OS/2, ..., typischerweise unter Linux mit Intel x86-Prozessoren)
    -> Infos zum Download der neuesten Entwicklerversion

top top

Verbesserungsvorschläge, Fragen und Anregungen an
Robert Baier ([e-mail-Adresse von Robert Baier])
© 2003 Robert Baier;
© 1999-2002 Robert Baier, Sascha Herrmann
Last modified: 22.07.2015