Concurrent Versions System

Historisches

Start 1986 als Sammlung von Shellskripten
seit 1989 als eigenständiges Programm entwickelt

Websites

CVS Homepage: http://www.cvshome.org/
Dort gibt es auch Dokumentation z.B. ein Manual im PDF Format
KDE Frontend: http://cervisia.sourceforge.net/
Windows Frontend: http://www.wincvs.org/

Was macht CVS

verwaltet Quelltexte (für Binärdateien nicht bzw. eingeschränkt benutzbar)
mehrere Programmierer/Programmierteams können unabhängig am gleichen Projekt arbeiten
sowohl zeitlich als auch räumlich unabhängig
hilft beim Dokumentieren von Änderungen am Quelltext
"rekonstruieren" des Quelltextes zum Stand eines beliebigen Datums seit Projektbeginn
- zur Fehlersuche
- Pflege von stabilen Releases
verwaltet/ermöglicht "branches"
- Pflege von stabilen Versionen (Bugfix releases)
- Experimente/Erweiterungen
- späteres Zusammenführen ist möglich

Wie macht CVS das

im Repository werden die Änderungen gespeichert und nicht jedesmal die kompletten Dateien
- diff und patch
pro Datei werden eine Revisionsnummer und das Datum des eincheckens gespeichert
abrufen des Quellcodes auf dem Stand eines bestimmten Datums. Sozusagen ein "replay" der Änderungen bis zum gewünschten Datum
Branches werden über die Revisionsnummer verwaltet

Der typische Arbeitszyklus

(login) (normalerweise einmalig)
auschecken des Quelltextes in das lokale Arbeitsverzeichnis (normalerweise einmalig)
Bearbeiten des Quelltextes
Update des Quelltext im Arbeitsverzeichnis und evt. Konflikte beseitigen
einchecken des Quelltextes ins Repository (auch hier evt. Konflikte beseitigen)
und wieder zu 3.

Befehle

Allgemeiner Aufruf: cvs [global options] command [command options] [args]

Die Befehle arbeiten fast alle...

im aktuellen Verzeichnis
rekursiv

Vorbereitungen

$CVSROOT auf das Verzeichnis des Repository setzen
- direkter Pfad, wenn es lokal erreichbar ist (z.B. in der Uni)
- :ext:<user>@<host>:<pfad> wenn sich das Repository auf einem Rechner im Internet befindet
  Zusätzlich muss $CVS_RSH auf eine Shell gesetzt werden, die zum einloggen benutzt wird. Für die Uni ist das die Secure Shell, also ssh
- :pserver:<user>@<host>:<pfad> wenn cvs als server läuft. Ist ziemlich unsicher und wird wohl deshalb in der Uni auch nicht gemacht
- alternativ kann man die globale Option -d <pfad> benutzen
login (in der Uni nicht nötig/möglich)
- wird nur benötigt wenn cvs als Server läuft
- nur einmal notwendig, Daten werden lokal gespeichert (~/.cvspass)
- ist nicht sehr sicher (besonders wenn kein extra Passwort für cvs benutzt wird, sondern das login Passwort verwendet wird)
- ~/.cvspass sollte nicht für group/others lesbar sein!!!
checkout <module>
- legt ein Verzeichnis mit dem Modulnamen an und kopiert alle Daten aus dem Repository in das Verzeichnis
- solange man das Verzeichnis nicht löscht ist das ein einmaliger Vorgang
- in jedem Verzeichnis existiert ein Unterverzeichnis mit dem Namen CVS in dem Verwaltungsdaten liegen
- man kann auch den Quelltext auf dem Stand eines bestimmten Datums auschecken
- oder den Quelltext eines Branch

Informationen über Dateien

status [<file(s)>]
- zeigt den Status von einer oder mehrerer Dateien an (siehe unten)
- gibt sozusagen eine Übersicht über die Aufgaben, die ein update lösen muss
diff <file(s)>
- zeigt Änderungen zwischen der/den Datei(en) im Arbeitsverzeichnis und dem Repository
- wenn man selber nicht mehr sogenau weiss was man geändert hat
- oder um zu sehen was jemand anderes inzwischen im Repository geändert hat
log <file>
- zeigt die Kommentare zu den einzelnen Revisionen der Datei an

Ein-/auschecken von Dateien

update [<file(s)>]
- bringt die Dateien im Arbeitsverzeichnis auf den aktuellen Stand des Repository
- kann zu Konflikten führen
commit [-m "<comment>"] [<file(s)>]
- lässt Änderungen im Arbeitsverzeichnis in das Repository einfliessen
- man muss einen Kommentar angeben
- der Kommentar sollte die Änderungen beschreiben damit andere Programmierer wissen was getan wurde (siehe log)
- der Editor den cvs aufruft um den Kommentar einzugeben wird in $CVSEDITOR oder $EDITOR festgelegt
- sonst wird ein Default benutzt (vi bei Unix, Notepad bei Windows)
- aus vi kommt man mit :q<enter> wieder heraus ;-)
- kurze Kommentare kann man auch gleich an der Kommandozeile angeben
add [-m "<comment>"] <file(s)>
- sagt cvs lokal, dass Dateien ins Repository übernommen werden sollen
- die Dateien werden erst mit einem commit wirklich übernommen
- der Kommentar ist im Gegensatz zu commit nicht obligatorisch
- dieser Befehl arbeitet nicht rekursiv!
- bei Binärdateien die Option -kb mit angeben
remove <file(s)>
- Datei muss vor diesem Befehl im Arbeitsverzeichnis gelöscht werden (rm, del o.ä.)
- wie bei add wird erstmal nur lokal vermerkt, das die Datei aus dem Repository gelöscht werden soll
- erst beim nächsten commit wird die Datei im Repository gelöscht (nicht wirklich...)
- mit der Option -f übernimmt cvs das löschen der Datei im Arbeitsverzeichnis
- Unterverzeichnisse löscht man, indem man alle Dateien darin löscht und beim nächsten update die globale Option -P angibt.

Globale Optionen

-d <cvsroot> gibt das Verzeichnis zum Repository an. Alternativ zur Umgebunsvariable.
-z n wobei n eine Ziffer von 0 bis 9 ist, gibt die Kompression (0=gar nicht, 9=stark) für die Übertragung der Daten an.

Mögliche Werte für den Status einer Datei

Up-to-date
lokale Datei und Repository sind identisch
Locally Modified
Datei im Arbeitsverzeichnis wurde verändert
Locally Added
Datei wurde im Arbeitsverzeichnis mit add "markiert"
Locally Removed
Datei wurde im Arbeitsverzeichnis mit remove als gelöscht "markiert"
Needs Checkout
Datei wurde im Repository geändert, d.h. eine geänderte Revision wurde eingecheckt.

Die Bezeichnung ist etwas irreführend, weil kein checkout, sondern ein update ausgeführt werden muss!!!
Needs Patch
Wie 'Needs Checkout' nur das ein Patch übertragen wird anstelle der gesamten Datei.
Needs Merge
Datei wurde sowohl im Repository als auch lokal im Arbeitsverzeichnis verändert und beide Revisionen müssen zusammengeführt werden. Hier können Konflikte auftreten.
Conflict
Wie 'Locally Modified', nur das ein vorhergehendes update einen Konflikt gemelded hat, der noch nicht aufgelöst wurde.
Unknown
Die Datei im lokalen Arbeitsverzeichnis ist cvs "unbekannt". Entweder wurde sie noch nicht mit add "markiert" oder die Datei gehört gar nicht ins Repository. Zum Beispiel *.class Dateien. Dann sollte man sie in die .cvsignore Datei aufnehmen.

Konflikte

Treten auf wenn eine Datei sowohl im Repository als auch lokal im Arbeitsverzeichnis geändert wurden und sich geänderte Zeilen überschneiden.

Wenn die Datei an unterschiedlichen Stellen geändert wurde, kann cvs beide Revisionen selbstständig zusammenführen.

Folgendes passiert bei einem Konflikt:

eine Sicherheitskopie mit dem Namen .#<dateiname>.<revisionsnummer> wird angelegt
die eigentliche Datei wird ersetzt durch eine in der die Konfliktstelle besonders gekennzeichnet ist und die Zeilen aus beiden Dateien enthalten sind. Das Format sieht so aus:
<<<<<<< <dateiname> ... Quelltext aus der lokalen Datei ... ======= ... Quelltext aus der Datei aus dem Repository ... >>>>>>> <revisionsnummer>