Tobias M.

Bölz

CVS
Eine Einführung
bölzebub.de

Dieser Inhalt ist unter einem Creative Commons Namensnennung-Nicht-

Kommerziell-Weitergabe unter gleichen Bedingungen Lizenzvertrag li-
zenziert. Um die Lizenz anzusehen, gehen Sie bitte zu http://creative-
commons.org/licenses/by-nc-sa/2.0/de/ oder schicken Sie einen Brief an
Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305,
USA.

2
Inhaltsverzeichnis

Vorwort 5

1 Einleitung 7
1.1 Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Beschaffung & Installation . . . . . . . . . . . . . . . . . . 9
1.5 Aufruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Zugriff auf ein Archiv . . . . . . . . . . . . . . . . . . . . 10
1.7 Vorbereitungen . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Archiv anlegen 13

3 Neues Projekt beginnen 15

4 Arbeitskopie auschecken 17

5 Veränderungen einbringen 19

6 Arbeitskopie aktualisieren 21

7 Konflikte 23

8 Status der Arbeitskopie 25

9 Log-Nachrichten lesen 27

3
Inhaltsverzeichnis

10 Vergleiche 29

11 Dateien hinzufügen und entfernen 31

11.1 Dateien hinzufügen . . . . . . . . . . . . . . . . . . . . . . 31
11.2 Binärdateien hinzufügen . . . . . . . . . . . . . . . . . . . 32
11.3 Dateien entfernen . . . . . . . . . . . . . . . . . . . . . . . 32

12 Marken 35

13 Verzweigungen 39
13.1 Projekt verzweigen . . . . . . . . . . . . . . . . . . . . . . 40
13.2 Zweige verschmelzen . . . . . . . . . . . . . . . . . . . . . 42

Anhang 47
A Befehle 47

B Literatur 49

4
Vorwort

Wer programmiert kennt das Problem: Gestern lief das Programm noch,
heute läuft es nicht mehr. Deshalb ist es wichtig, die Veränderungen
nachvollziehen zu können. Um nicht jede Änderung selbst speichern zu
müssen, gibt es Versionskontrollsysteme. Das wahrscheinlich am weites-
ten verbreitete ist das CVS – das Concurrent Versions System.

Um die Beispiele in diesem Buch nachvollziehen zu können, ist es

sinnvoll, schon einmal unter einem UNIX-ähnlichen-Betriebssystem mit
der Konsole gearbeitet zu haben. Wer die ersten Seiten eines C-Buches
gelesen hat, versteht auch das verwendete Beispielprogramm1 .

Das CVS kann natürlich viel mehr, als auf diesen nicht ganz 50 Seiten
beschrieben werden kann. Dies soll – wie der Titel schon sagt – auch nur
eine Einführung sein.

1 Für alle anderen: Die main()-Funktion wird beim starten des Programms aus-

geführt, printf() gibt eine Zeichenkette auf der Konsole aus

5
Vorwort

6
Kapitel 1

Einleitung

CVS, das Concurrent Versions System1 , ist das führende Open-Source-

Versionskontrollsystem.
Es ist zur Verwaltung aller Arten von Textdateien geeignet, d. h.
es können nicht nur Quelltexte von Programmen, sondern auch z. B.
HTML-Seiten oder LATEX-Dokumente verwaltet werden.
Es ist (zumindest als Client) für fast alle Plattformen verfügbar. Es ist
also möglich, plattformunabhängige Programme auch von verschiedenen
Plattformen aus zu entwickeln.
Da es freie Software ist, wird es zur Verwaltung vieler Open-Source-
Projekte wie z. B. Mozilla, OpenOffice.org oder KDE verwendet. Auf
sourceforge.net werden für über 60.000 Projekte CVS-Server zur Verfüg-
ung gestellt. Dort ist z. B. der Java-Applikations-Server JBoss oder das
Xbox-Linux-Projekt gehostet.

1.1 Geschichte
CVS basiert grundlegend auf dem Standard-Unix-Programm diff, ei-
nem Programm zum vergleichen zweier Dateien, und dessen Erweiterung
patch von Larry Wall. Wird patch eine Datei mit den Änderungen, ein
sogenannter Patch, übergeben, fügt es die Änderungen in die entspre-
chenden Dateien ein.
1 System konkurrierender Versionen

7
Einleitung

Auf diese Programmen baute auch schon das Revision Control Sys-
tem RCS von Walter Tichys auf. Dieses Versionskontrollsystem hatte
jedoch einige Nachteile, z. B. musste eine Datei erst gesperrt werden,
bevor man sie bearbeiten konnte. Es war also nicht möglich, dass zwei
Entwickler gleichzeitig an einer Datei arbeiten.
Deshalb wurde das CVS geschrieben. Die erste Version war eine
Sammlung von Shell-Skripten von Dick Grune, die das RCS so aufrief,
dass viele Probleme umgangen wurden. 1989 schrieben Brian Berliner
und Jeff Polk das CVS in der Programmiersprache C neu. Später erwei-
terte Jim Kingdon es um die Netzwerkfähigkeit.

1.2 Konventionen
Dateien, Internetadressen, etc. werden kursiv geschrieben.

Befehle werden generell in Schreibmaschinenschrift dargestellt. Wird

der Aufruf eines Programms beschrieben, stehen optionale Argument
in eckigen Klammern, Argumente, die kursiv geschrieben sind, müssen
ersetzt werden. Z.B.:

cvs import [Optionen ]Projektname Hersteller Versions-Marke

Kommandozeilenbeispiele werden in Schreibmaschinenschrift und ein-

gerückt dargestellt:

[tmb@fuckupII tmb]$ whoami

tmb
[tmb@fuckupII tmb]$

Hier wird der Aufruf des Programms an einem Beispiel demonstriert.

Als Shell kommt die bash zum Einsatz. Deshalb werden auch alle
Umgebungsvariablen mit einem $ gekennzeichnet, z.B. $CVSROOT.

1.3 Terminologie
Am Anfang sollten noch ein paar Begriffe geklärt werden:

8
 1.4 Beschaffung & Installation

Archiv (repository) Das Verzeichnis, in dem das CVS zentral das Pro-
jekt mit allen Veränderungen speichert.
Arbeitskopie Die (lokale) Kopie, mit der der Entwickler arbeitet. Nur
an ihr werden direkt Veränderungen vorgenommen, die dann ins
Archiv übernommen werden.
Revision Die Revisionsnummer wird vom CVS intern verwendet. Sie
bezieht sich auf eine einzelne Datei, nicht auf das gesamte Pro-
gramm, und wird bei jeder Veränderung erhöht.

1.4 Beschaffung & Installation

CVS wird bei den meisten Linux-Distributionen mitgeliefert. Bei Mac
OS X befindet es sich im Developer-Packet. Ansonsten kann es unter
www.cvshome.org/downloads.html für die meisten Plattformen herunter
geladen werden.
Da sich die Installation von Plattform zu Plattform unterscheidet,
werde ich nicht darauf eingehen. Bitte beachten Sie dazu die README -
und INSTALL-Dateien der jeweiligen Distribution.
Zu beachten ist, dass es sich bei den Versionen für Macintosh (Sys-
teme bis Mac OS 9) und Windows nur um Clients handelt, mit ihnen
kann kein Server aufgesetzt werden.

1.5 Aufruf
Der Aufruf des CVS sieht folgendermaßen aus:
cvs [globale Optionen] Befehl [Befehlsoptionen] [Dateien]
Das CVS kann viele verschiedene Operation durchführen. Für sie gibt
es jeweils einen Befehl. Außerdem können noch globale Optionen, die
für alle Befehle gelten, und Befehlsoptionen, die vom jeweiligen Befehl
abhängig sind, angegeben werden. Desshalb ist z. B. cvs -d /usr/local/
archiv checkout nicht dasselbe wie cvs checkout -d /usr/local/archiv.
Manche Befehle benötigen noch (eine) Datei(en) als Argument. Diese
werden/wird als letztes übergeben.
Für die meisten Befehle gibt es Alternativen, hauptsächlich Kurzfor-
men und die Namen der Befehle des RCS (siehe Anhang A).

9
Einleitung

1.6 Zugriff auf ein Archiv

Das Archiv, auf das zugegriffen werden soll, wird mit dem (globalen)
Argument -d2 angegeben. Bei einem lokalen Archiv wird einfach der
absolute Pfad angegeben, z. B. cvs -d /usr/local/archiv Befehl .
Soll über das Netzwerk bzw. das Internet auf ein Archiv zugegrif-
fen werden, muss zusätzlich die Zugriffsmethode, der Rechner und der
Benutzername angegeben werden. Dazu wird folgende Zeichenkette ver-
wendet:
:Zugriffsmethode :Benutzer @Rechner :Verzeichnis
Die wichtigsten Zugriffsmethoden sind:
ext Verwendet rsh, ssh oder ein anderes externes Programm, um die
Verbindung zum Server aufzubauen. Das Programm, das verwen-
det werden soll, muss in der Umgebungsvariable $CVS RSH ste-
hen.
server Verwendet die interne rsh-Implementation.
pserver Benutzt den Passwortauthentifizierungs-Server. Diese Methode
wird oft für den anonymen Zugriff verwendet.
local Greift auf eine lokales Archiv zu. Wie schon erwähnt, reicht es aus,
nur das Verzeichnis, in dem sich das Archiv befindet, anzugeben.

1.7 Vorbereitungen
Umgebungsvariablen
Wer immer auf dasselbe Archiv zugreifen will, sollte $CVSROOT setzen.
Daduch wird die Angabe des Archivs mit -d überflüssig.
In einer der Variablen $CVSEDITOR, $VISUAL oder $EDITOR soll-
te der bevorzugte Editor stehen, sonst wird vi verwendet.
Soll auf ein Archiv mit der ext-Methode zugegriffen werden, muss
auch $CVS RSH gesetzt sein, wenn nicht die rsh genutzt werden soll.
Unter Windows muss noch entweder $HOME oder $HOMEDRIVE
und $HOMEPATH gesetzt sein, da im entsprechenden Verzeichnis die
benutzerspezifischen Konfigurationsdateien gespeichert werden.
2 für directory (Verzeichnis)

10
 1.7 Vorbereitungen

Zu ignorierende Dateien
Wer programmiert testet seine Veränderungen auch hin und wieder. Das
ausführbare Programm, die Objektdateien, etc. sollten jedoch nicht in
das Archiv übernommen werden. Das CVS lässt sich so einstellen, das
es diese Dateien und Dateitypen ignoriert.
Dazu gibt es drei Möglichkeiten:
• Für alle Benutzer: Die Datei cvsignore im /etc-Verzeichnis
• Die Datei .cvsignore im Heimatverzeichnis

• Die Umgebungsvariable $CVSIGNORE

Da das CVS das Zeilenende an die jeweilige Plattform anpasst und
Schlüsselwörter in den Dateien ersetzt, sollten hier auch Bilder und an-
dere Binärdateien angegeben werden, weil diese sonst zerstört werden
können. Sie sollten explizit zum Projekt hinzugefügt werden (siehe Ka-
pitel 11.2: Binärdateien hinzufügen).
Es können reguläre Ausdrücke3 verwendet werden.
Eine typische .cvsignore eines Java-Entwicklers sähe z. B. folgender-
masen aus:
*.class
*.png
.desktop
Neben den kompilierten Java-Klassen werden hier auch png-Bilder
und .desktop-Dateien, in denen KDE die Ansichtsoptionen des Ordners
speichert, ignoriert.

3 siehe man grep

11
Einleitung

12
Kapitel 2

Archiv anlegen

Um das CVS nutzen zu können, muss ein Archiv vorhanden sein. Ein
lokales Archiv kann man mit

cvs init

angelegen. Der Ordner, in dem es angelegt werden soll, wird mit der
globalen Option -d angegeben. Für das entsprechende Verzeichnis muss
man Schreibrechte haben.

Beispiel:

[tmb@fuckupII tmb]$ sudo cvs -d /usr/local/archiv init

Password:
[tmb@fuckupII tmb]$ ls -l /usr/local/archiv/
total 0
drwxrwxr-x 36 root wheel 1224 Dec 24 17:39 CVSROOT
[tmb@fuckupII tmb]$ ls /usr/local/archiv/CVSROOT/
checkoutlist cvswrappers loginfo,v rcsinfo,v
checkoutlist,v cvswrappers,v modules taginfo
commitinfo editinfo modules,v taginfo,v
commitinfo,v editinfo,v notify verifymsg
config history notify,v verifymsg,v
config,v loginfo rcsinfo
[tmb@fuckupII tmb]$

13
Archiv anlegen

In der ersten Zeile wird das Archiv angelegt. Das ganze wird als root
ausgeführt (sudo), da Schreibberechtigung vorliegen muss.
Im entsprechenden Verzeichnis wird der Ordner CVSROOT ange-
legt. Darin werden die Konfigurationsdateien des Archivs gespeichert.

Mit CVS einen Server aufzusetzen ist wesentlich komplizierter. Wie

man an den Zugriffsmethoden schon sieht gibt es dazu auch mehre-
re Möglichkeiten. Diese zu erklären würde den Rahmen dieses Buches
sprengen.

14
Kapitel 3

Neues Projekt beginnen

Um ein Projekt mit CVS zu verwalten, muss es mit

cvs import Projektname Hersteller-Marke Versions-Marke
in ein Archiv importiert werden. Es werden alle Dateien des aktuellen
Verzeichnis und seiner Unterverzeichnisse zum Projekt Projektname hin-
zugefügt.
Hersteller-Marke und Versions-Marke spielen in diesem Zusammen-
hang eigentlich keine Rolle. Als Hersteller-Marke verwendet man meis-
tens seinen Benutzernamen, als Versions-Marke start.
Außerdem sollte mit der Befehlsoption -m1 direkt eine Nachricht an-
gegeben werden, sonst wird automatisch der Editor geöffnet, wo die
Nachricht eingegeben werden muss.

1 für message (Nachricht)

15
Neues Projekt beginnen

Beispiel:
[tmb@fuckupII tmb]$ export CVSROOT=/usr/local/archiv
[tmb@fuckupII tmb]$ cd meinprojekt/
[tmb@fuckupII meinprojekt]$ ls
hallo.c readme sinnlos.h unterverzeichnis/
[tmb@fuckupII meinprojekt]$ cat hallo.c
#include <stdio.h>

int main(void)
{
printf("Hallo, Welt!\n");
return 0;
}
[tmb@fuckupII tmb]$ cvs import -m "erster Import"
hallo tmb start
N meinprojekt/hallo.c
N meinprojekt/readme
N meinprojekt/sinnlos.h
cvs import: Importing
/usr/local/archiv/meinprojekt/unterverzeichnis
N meinprojekt/unterverzeichnis/blabla.c

No conflicts created by this import

[tmb@fuckupII tmb]$
Als erstes wird $CVSROOT auf das vorher angelegte Archiv gesetzt.
Das Beispielprojekt befindet sich im Ordner meinprojekt. Das eigentli-
che Programm ist hallo.c. Das Projekt wird unter dem Namen hallo in
das Archiv importiert.

Man kann jetzt jedoch nicht mit den ursprünglichen Dateien weiter-
arbeiten. Es muss erst eine Arbeitskopie angelegt werden.

16
Kapitel 4

Arbeitskopie auschecken

Eine Arbeitskopie legt man mit

cvs checkout Projektname

an. Dabei wird im aktuellen Verzeichnis ein Ordner mit dem Namen des
Projekts angelegt. Ist $CVSROOT nicht gesetzt oder soll ein anderes
Archiv verwendet werden, muss die -d-Option verwendet werden.

Beispiel:

[tmb@fuckupII tmb]$ cvs checkout hallo

cvs checkout: Updating hallo
U hallo/hallo.c
U hallo/readme
U hallo/sinnlos.h
cvs checkout: Updating hallo/unterverzeichnis
U hallo/unterverzeichnis/blabla.c
[tmb@fuckupII tmb]$ ls hallo/
CVS/ readme unterverzeichnis/
hallo.c sinnlos.h
[tmb@fuckupII tmb]$

Es wird eine Arbeitskopie des Projekts hallo angelegt. Im Verzeichnis

der Arbeitskopie wird neben den Dateien des Projekts auch der Ordner

17
Arbeitskopie auschecken

CVS erstellt. Darin speichert das CVS Informationen über die einzelnen
Dateien und das Archiv, in dem das Projekt verwaltet wird.

18
Kapitel 5

Veränderungen
einbringen

Veränderungen, die man in der Arbeitskopie gemacht hat, werden mit

cvs commit
in das Archiv übernommen. Da die Adresse des Archivs in der Arbeitsko-
pie gespeichert wird, benötigt commit keine Optionen. Es sollte jedoch,
wie bei import, direkt mit -m eine Nachricht angegeben werden.

Beispiel:
[tmb@fuckupII hallo]$ vi hallo.c
[. . . ]

[tmb@fuckupII hallo]$ cat hallo.c

#include <stdio.h>

int main(void)
{
printf("Hallo, Welt!\n");
printf("tschuess!\n");
return 0;
}

19
Veränderungen einbringen

[tmb@fuckupII hallo]$ cvs update

cvs update: Updating .
M hallo.c
cvs update: Updating unterverzeichnis
[tmb@fuckupII hallo]$ cvs commit -m "massive erweiterung"
cvs commit: Examining .
cvs commit: Examining unterverzeichnis
Checking in hallo.c;
/usr/local/archiv/hallo/hallo.c,v <-- hallo.c
new revision: 1.2; previous revision: 1.1
done
[tmb@fuckupII hallo]$

Die Datei hallo.c wurde verändert. Nach Hallo, Welt! wird jetzt noch
 tschuess! ausgegeben.
Vor dem Commit wird wird cvs update ausgeführt (siehe Kapitel
6: Arbeitskopie aktualisieren). Dabei wird überprüft, ob es im Archiv
evtl. eine neuere Revision einer Datei gibt. Dann kann das Commit nicht
durchgeführt werden. Wer das CVS nur allein verwendet, kann auf diesen
Schritt verzichten.
Beim Commit untersucht das CVS als erstes die Arbeitskopie auf
veränderte Dateien. Diese werden dann in das Archiv übernommen, die
Revisionen der entsprechenden Dateien werden erhöht.

20
Kapitel 6

Arbeitskopie
aktualisieren

Um Veränderungen im Archiv, d. h. die Veränderungen der anderen

Entwickler, in die eigene Arbeitskopie zu übernehmen gibt es den Befehl
cvs update
Er zeigt es auch an, wenn die Datei in der Arbeitskopie verändert
wurde.

Beispiel 1:
[tmb@fuckupII hallo]$ cvs update
cvs update: Updating .
U hallo.c
cvs update: Updating unterverzeichnis
[tmb@fuckupII hallo]$
Die Datei hallo.c wurde von einem anderen Entwickler verändert. Die
Veränderungen wurden in die Arbeitskopie übernommen (Das U vor
hallo.c steht für update).

21
Arbeitskopie aktualisieren

Beispiel 2:
[tmb@fuckupII hallo]$ cvs update
cvs update: Updating .
M hallo.c
cvs update: Updating unterverzeichnis
[tmb@fuckupII hallo]$
Hier gibt es keine neueren Revisionen im Archiv, das M1 vor hal-
lo.c sagt jedoch aus, dass diese Datei von einem selbst verändert wurde.

1 für modified (verändert)

22
Kapitel 7

Konflikte

Zu einem Konflikt kommt es bei einem Update, wenn man in der Arbeits-
kopie an einer Stelle etwas verändert, die inzwichen schon von jemand
anderem verändert und per Commit ins Archiv übernommen wurde.

Beispiel:

[tmb@fuckupII hallo]$ cvs update hallo.c

RCS file: /usr/local/archiv/hallo/hallo.c
retrieving revision 1.2
retrieving revision 1.3
Merging differences between 1.2 and 1.3 into hallo.c
rcsmerge: warning: conflict during merge
cvs update: conflicts found in hallo.c
C hallo.c
[tmb@fuckupII hallo]$

Beim Update von hallo.c trat ein Konflikt auf. Doch das CVS zeigt
dies nicht nur an, sondern fügt nun auch beide Veränderungen in folgen-
der Form in die Datei ein:

[. . . ]
<<<<<<< Dateiname
Eigene Veränderung
=======

23
Konflikte

Veränderung im Archiv
>>>>>>> Revision
[. . . ]

Jetzt sollte man den Konflikt beheben und danach die konflikfreie
Version per Commit ins Archiv übernehmen. Dabei sollte man sich aber
auf jeden Fall mit dem anderen Entwickler absprechen und nicht einfach
die eigene Änderung übernehmen, sonst arbeitet dieser (oder Sie) ganz
schnell an einem anderen Projekt.

24
Kapitel 8

Status der Arbeitskopie

Den Status einer Datei kann man mit

cvs status [Datei ]

anzeigen. Wenn keine Datei angegeben wird, wird der Status jeder Datei
des Projekts angezeigt.

Beispiel:

[tmb@fuckupII hallo]$ cvs status hallo.c

========================================================
File: hallo.c Status: Up-to-date

Working revision: 1.3 Mon Mar 24 13:42:24 2003

Repository revision: 1.3 /usr/local/archiv/hallo/
hallo.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)

[tmb@fuckupII hallo]$

Die Datei ist hier also Up-to-date, d. h. sie entspricht der im Archiv.
Es können aber auch andere Statuse auftreten:

25
Status der Arbeitskopie

• Locally Modified heißt, dass die Datei in der Arbeitskopie verän-

dert wurde.
•  Needs Patch bedeutet, dass die Datei von jemand anderem
verändert wurde. Dann ist die Revisionsnummer hinter Repository
revision höher als die hinter Working revision. Die Änderungen
werden beim nächsten Update übernommen.
• Bei Needs Merge wurde die Datei von jemand anderem an
der selben Stelle verändert, wie von Ihnen. Diese Veränderungen
müssen zusammengeführt werden. Wenn jetzt ein Update durch-
geführt wird, kommt es zu einem Konflikt.
Sticky Tag 1 oder Sticky Date 2 sind nur vorhanden, wenn ein Commit
bzw. Update mit einer Marke oder einem Datum durchgeführt wurde
(siehe Kapitel 12: Marken).
Sticky Options sind Optionen, die einer Datei zugeordnet sind, bis
sie wieder abgeschaltet werden.

1 Haftende Marke
2 Haftendes Datum

26
Kapitel 9

Log-Nachrichten lesen

Um einen groben Überblick über die Veränderungen verwendet man

cvs log [Datei ]

Wenn keine Datei angegeben wird, werden auch hier alle Dateien bear-
beitet.

Beispiel:

[tmb@fuckupII hallo]$ cvs log hallo.c

RCS file: /usr/local/archiv/hallo/hallo.c,v

Working file: hallo.c
head: 1.3
branch:
locks: strict
access list:
symbolic names:
start: 1.1.1.1
tmb: 1.1.1
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
----------------------------

27
Log-Nachrichten lesen

revision 1.3
date: 2003/03/24 13:44:53; author: tmb; state: Exp;
lines: +1 -1
weitere verbesserung
----------------------------
revision 1.2
date: 2003/03/24 13:36:09; author: tmb; state: Exp;
lines: +1 -0
massive erweiterung
----------------------------
revision 1.1
date: 2003/03/24 13:30:11; author: tmb; state: Exp;
branches: 1.1.1;
Initial revision
----------------------------
revision 1.1.1.1
date: 2003/03/24 13:30:11; author: tmb; state: Exp;
lines: +0 -0
Erster import des grandiosen Hallo-Welt-Programms
========================================================
[tmb@fuckupII hallo]$
Neben den eingegebenen Nachrichten zeigt cvs log auch das Da-
tum und den Autor der Veränderung. Die Angaben hinter lines: geben
Aufschluss darüber, wie viel verändert wurde.

28
Kapitel 10

Vergleiche

Um mehr über die Veränderungen zwischen den Revisionen zu erfahren,

gibt es mehrere Möglichkeiten, diese zu vergleichen:
cvs diff Datei
vergleicht die aktuelle Datei mit der Basisrevision, der Revision des letz-
ten updates. Mit
cvs diff -r Revision Datei
kann man die Datei in der Arbeitskopie mit der angegebenen Revision
im Archiv vergleichen.
cvs diff -r Revision1 -r Revision2

verglicht Revision1 mit Revision2.

Statt -r Revision kann man auch -D Datum verwenden. Dabei wird
die neueste Revision, die nicht älter als Datum ist, verwendet.
Außerdem gibt es noch eine Reihe Optionen, die mit denen des nor-
malen GNU-diff -Programms übereinstimmen. Die wichtigste ist wahr-
scheinlich -c1 . Dadurch wird die Zeile vor und nach dem Unterschied
auch angezeigt.

1 für context

29
Vergleiche

Beispiel:
[tmb@fuckupII hallo]$ cvs diff hallo.c
Index: hallo.c
========================================================
RCS file: /usr/local/archiv/hallo/hallo.c,v
retrieving revision 1.2
diff -r1.2 hallo.c
6c6
< printf("tschuess!");
---
> printf("Tschuess, Welt!");
[tmb@fuckupII hallo]$ cvs diff -c hallo.c
Index: hallo.c
========================================================
RCS file: /usr/local/archiv/hallo/hallo.c,v
retrieving revision 1.2
diff -c -r1.2 hallo.c
*** hallo.c 2003/03/24 13:36:09 1.2
--- hallo.c 2003/03/24 13:42:24
***************
*** 3,8 ****
int main(void)
{
printf("Hallo, Welt!\n");
! printf("tschuess!");
return 0;
}
--- 3,8 ----
int main(void)
{
printf("Hallo, Welt!\n");
! printf("Tschuess, Welt!");
return 0;
}
[tmb@fuckupII hallo]$
Vergleich von hallo.c mit der Basisrevision, oben ohne, unten mit
Kontext.

30
Kapitel 11

Dateien hinzufügen und

entfernen

11.1 Dateien hinzufügen

Hin und wieder kommt es vor, dass zu einem Projekt eine neue Datei
hinzugefügt werden muss. Dies geht mit

cvs add Datei

Dadurch wird aber nur in der Arbeitskopie vermerkt, dass die Datei zum
Projekt gehört. Um die Datei in das Archiv zu übernehmen, muss ein
commit durchgeführt werden.

Beispiel:

[tmb@fuckupII hallo]$ echo "So ziemlich alles" > TODO

[tmb@fuckupII hallo]$ cvs add TODO
cvs add: scheduling file ‘TODO’ for addition
cvs add: use ’cvs commit’ to add this file permanently
[tmb@fuckupII hallo]$ cvs commit -m "TODO hinzugefuegt"
cvs commit: Examining unterverzeichnis
RCS file: /usr/local/archiv/hallo/TODO,v
done

31
Dateien hinzufügen und entfernen

Checking in TODO;
/usr/local/archiv/hallo/TODO,v <-- TODO
initial revision: 1.1
done
[tmb@fuckupII hallo]$
Zuerst wird die Datei TODO erstellt. Mit cvs add wird sie zum Projekt
hinzugefügt und dann mit cvs commit in das Archiv übernommen.

11.2 Binärdateien hinzufügen

Das Hinzufügen von Binärdateien funktioniert ebenfalls mit add :
cvs add -kb Datei
Hier wird allerdings mit -kb die Schlüsselwortersetzung und das Ersetzen
der Zeilenenden abgeschaltet.

11.3 Dateien entfernen

Um eine Datei aus dem Projekt zu entfernen gibt es den Befehl
cvs remove Datei
Die Datei muss erst gelöscht werden. Wie bei add wird das Archiv erst
beim nächsten commit verändert. Die Datei wird im Archiv nur als
gelöscht markiert, da sie von älteren Revisionen anderer Dateien evtl.
benötigt wird.

Beispiel:
[tmb@fuckupII hallo]$ rm sinnlos.h
[tmb@fuckupII hallo]$ cvs remove sinnlos.h
cvs remove: scheduling ‘sinnlos.h’ for removal
cvs remove: use ’cvs commit’ to remove this file permanently
[tmb@fuckupII hallo]$ cvs commit -m "sinnlos.h geloescht"
cvs commit: Examining .
cvs commit: Examining unterverzeichnis
Removing sinnlos.h;

32
 11.3 Dateien entfernen

/usr/local/archiv/hallo/sinnlos.h,v <-- sinnlos.h

new revision: delete; previous revision: 1.1.1.1
done
[tmb@fuckupII hallo]$
Als erstes wird die Datei sinnlos.h gelöscht. Danach wird sie mit cvs
remove zum entfernen vorgemerkt und dann mit cvs commit in Archiv
als gelöscht markiert.

33
Dateien hinzufügen und entfernen

34
Kapitel 12

Marken

Mit einer Marke kann man die zusammengehörenden Revisionen der

Dateien markieren.
Datei A Datei B Datei C
1.1 1.1
1.2
1.3 1.2 1.1
1.4 1.2
1.5 1.3 1.3
1.6 1.4
1.7 1.4 1.5
Marke
Damit kann man lauffähige Versionen markieren, um später direkt
auf diese zugreifen zu können.
Eine Marke setzt man mit den Befehl
cvs tag Name
Dabei werden die Revisionen der Dateien der Arbeitskopie mit der Marke
Name markiert.
Der Name der Marke muss mit einem Buchstaben beginnen und darf
nur Buchstaben, Ziffern, Bindestriche und Unterstriche enthalten.

35
Marken

Beispiel:

[tmb@fuckupII hallo]$ cvs tag version1

cvs tag: Tagging .
T TODO
T hallo.c
T readme
cvs tag: Tagging unterverzeichnis
T unterverzeichnis/blabla.c
[tmb@fuckupII hallo]$

Der jetzige Stand des Projekts wurde mit der Marke version1 gekenn-
zeichnet.

Um auf eine markierte Revision zuzugreifen verwendet man ebenfalls

die -r-Option.

Beispiel:

[tmb@fuckupII tmp]$ cvs checkout -r version1 hallo

cvs checkout: Updating hallo
U hallo/TODO
U hallo/hallo.c
U hallo/readme
cvs checkout: Updating hallo/unterverzeichnis
U hallo/unterverzeichnis/blabla.c
[tmb@fuckupII tmp]$ cd hallo/
[tmb@fuckupII hallo]$ ls
CVS hallo.c unterverzeichnis
TODO readme
[tmb@fuckupII hallo]$ cvs status
cvs status: Examining .
========================================================
File: TODO Status: Up-to-date

Working revision: 1.1 Mon Mar 24 13:49:16 2003

Repository revision: 1.1 /usr/local/archiv/hallo/
TODO,v
Sticky Tag: version1 (revision: 1.1)

36
 Sticky Date: (none)
Sticky Options: (none)

========================================================
File: hallo.c Status: Up-to-date

Working revision: 1.3 Mon Mar 24 13:44:53 2003

Repository revision: 1.3 /usr/local/archiv/hallo/
hallo.c,v
Sticky Tag: version1 (revision: 1.3)
Sticky Date: (none)
Sticky Options: (none)

========================================================
[. . . ]

[tmb@fuckupII hallo]$

Hier wird ein Checkout mit der Marke version1 durchgeführt. Wie
cvs status anzeigt ist in der so neu angelegten Arbeitskopie versi-
on1 haftende Marke. Dies bedeutet, dass diese Arbeitskopie nicht ak-
tualisiert werden und man Veränderungen nicht ins Archiv übernehmen
kann.

37
Marken

38
Kapitel 13

Verzweigungen

Man kann mit dem CVS ein Projekt in mehrere Zweige spalten. Wird ein
Zweig verändert, betrifft dies den anderen nicht. Die einzelnen Zweige
können jedoch wieder verschmolzen, d. h. die Veränderungen des einen
in den anderen übernommen, werden.

Zweig -
Verschmelzung
? -
Hauptentwicklungslinie

Es ist auch möglich, an einer Stelle mehrere Zweige zu erstellen und

einen Zweig weiter zu verzweigen.
In den Zweigen werden andere Revisionsnummern vergeben: Der ers-
te Zweig hat die Nummer der ursprünglichen Revision mit .2 an-
gehängt, z. B. 1.3.2 oder 1.27.8.45.2. Beim zweiten Zweig wird .4 an-
gehängt, beim dritten .6 usw. Die Revisionen werden dann in ei-
ner weiteren Nummer hochgezählt, z. B. 1.3.2.1, 1.3.2.2, . . . oder auch
1.27.8.45.2.13.
Dies ist z. B. dann sinnvoll, wenn in einer stabilen Version 1.0 ein
Fehler behoben werden soll, während schon in Richtung Version 2.0 ent-
wickelt wird. Kurz bevor die Version 2 fertiggestellt wird werden die
Bugfixes der 1. Version dann übernommen.

39
Verzweigungen

13.1 Projekt verzweigen

Um einen Zweig zu erstellen müssen zwei Schritte durchgeführt werden:

1. Es muss eine Marke mit der -b1 -Option gesetzt werden:

cvs tag -b Zweig-Marke

Es ist sinnvoll, im Namen der Marke klar zu machen, dass es sich

um einen Zweig handelt, indem man -zweig, -branch oder
ähnliches anhängt, vor allem weil Projekte oft an Stellen verzweigt
werden, an denen es schon Marken gibt.

2. Um mit dem Zweig arbeiten zu können legt man mit

cvs checkout -r Zweig-Marke -d Ordner Projektname

eine neue Arbeitskopie an. Die Befehlsoption -d2 gibt dabei an, wo
diese erstellt wird.

Beispiel:

[tmb@fuckupII hallo]$ cvs tag -b version1-zweig

cvs tag: Tagging .
T TODO
T hallo.c
T readme
cvs tag: Tagging unterverzeichnis
T unterverzeichnis/blabla.c
[tmb@fuckupII hallo]$ cd ..
[tmb@fuckupII tmb]$ cvs checkout -r version1-zweig -d
hallo1 hallo
cvs checkout: Updating hallo1
U hallo1/TODO
U hallo1/hallo.c
U hallo1/readme
cvs checkout: Updating hallo1/unterverzeichnis
1 für branch (Zweig)
2 für directory

40
 13.1 Projekt verzweigen

U hallo1/unterverzeichnis/blabla.c
[tmb@fuckupII tmb]$ cd hallo1/
[tmb@fuckupII hallo1]$ ls
CVS hallo.c unterverzeichnis
TODO readme
[tmb@fuckupII hallo1]$ cvs status hallo.c
========================================================
File: hallo.c Status: Up-to-date

Working revision: 1.3 Mon Mar 24 13:44:53 2003

Repository revision: 1.3 /usr/local/archiv/hallo/
hallo.c,v
Sticky Tag: version1-zweig (branch: 1.3.2)
Sticky Date: (none)
Sticky Options: (none)

[tmb@fuckupII hallo1]$
Die Marke version1-zweigwurde mit der -b-Option gesetzt. Danach
wurde mit cvs checkout -r version1-zweig -d hallo1 hallo eine
neue Arbeitskopie des Zweigs version1-zweig des Projekts hallo in
dem Ordner hallo1 angelegt. cvs status, am Beispiel von hallo.c, zeigt
an, dass es sich um einen Zweig handelt.
Obwohl hier auch ein sticky Tag gesetzt ist können trotzdemÄnde-
rungen vorgenommen werden, da es sich um einen Zweig handelt.

41
Verzweigungen

13.2 Zweige verschmelzen

Um zwei Zweige zu verschmelzen, führt mann ein Update mit der -j3 -
Option in der Arbeitskopie durch, in die die Veränderungen des Zweigs
eingefügt werden sollen:

cvs update -j Zweig-Marke

Dabei wird nur die Arbeitskopie verändert. Um die Veränderungen in

das Archiv zu übernehmen, muss ein Commit durchgeführt werden.

Beispiel:

[tmb@fuckupII hallo]$ cvs update -j version1-zweig

cvs update: Updating .
RCS file: /usr/local/archiv/hallo/hallo.c,v
retrieving revision 1.3
retrieving revision 1.3.2.1
Merging differences between 1.3 and 1.3.2.1 into hallo.c
cvs update: Updating unterverzeichnis
[tmb@fuckupII hallo]$ cvs update
cvs update: Updating .
M hallo.c
cvs update: Updating unterverzeichnis
[tmb@fuckupII hallo]$ cvs commit -m "mit version1-zweig
verschmolzen"
cvs commit: Examining .
cvs commit: Examining unterverzeichnis
Checking in hallo.c;
/usr/local/archiv/hallo/hallo.c,v <-- hallo.c
new revision: 1.4; previous revision: 1.3
done
[tmb@fuckupII hallo]$

Zuerst wird der Zweig version1-zweig mit der Arbeitskopie verschmolzen.

Nur hallo.c wurde verändert und wird jetzt zusammengeführt. Danach
wandern die Veränderungen per Commit in das Archiv.

3 für join (verbinden, zusammenfügen)

42
 13.2 Zweige verschmelzen

Im Normalfall treten beim Verschmelzen einige Konflikte auf, weil so-

wohl der Zweig als auch die Hauptentwicklungslinie an der selben Stel-
len verändert wurden. Diese müssen dann vor einem Commit behoben
werden.

43
Verzweigungen

44
Anhang

45
Anhang A

Befehle
Befehl Alternativen Beschreibung Seite
init keine Neues Archiv 13
import im, imp Neues Projekt beginnen 15
checkout co, get Arbeitskopie auschecken 17
commit ci, comm Veränderungen einbringen 19
update up, upd Arbeitskopie aktualisieren 21
status st, stat Status anzeigen 25
log lo, rlog Log-Nachrichten anzeigen 27
diff di, dif Dateien/Revisionen vergleichen 29
add ad, new Datei hinzufügen 31
remove rm, delete Datei entfernen 32
tag ta, freeze Marke setzen 35

47
Befehle

48
Anhang B

Literatur

• Per Cederqvist et al: Version Management with CVS.

info cvs
doc/ -Verzeichnis der CVS-Distribution
http://www.cvshome.org/docs/manual/
• Karl Fogel: Open Source-Projekte mit CVS.
2002, MITP-Verlag; ISBN: 3-8266-0816-X
http://cvsbook.red-bean.com/translations/german

49