Kefk Network :  Open Source & Free Software |  About |  Wiki. Suchen | Index | Inhalt | Site Map | What's New?
Akteure | Geschichte | Freie Software | Open Source Software | Projekte | Ressourcen | Sammlungen.

CVS

Concurrent Versions System

OS und OC : Projekte : CVS : Übersicht
21-Nov-2001/03-Feb-06


Übersicht

CVS for Dummies,
SuSE Linux Knowledge Portal : Linux auf dem Server : CVS for Dummies

Bernd Loechner, Andreas Jaeger

Inhaltsverzeichnis

Einleitung
Motivation
Der Ansatz von CVS
Einsatz von CVS
Weitere Dokumentation
Die wichtigsten Kommandos
Vorbereitungen
Änderungen synchronisieren
Neue Dateien registrieren
Dateien löschen
Versionsinformationen im Quelltext
Handhabung aus dem Emacs/XEmacs
Ergänzungen
Einrichten eines globalen CVS-Verzeichnisses
Einrichten eines Projektes
Lokale und Remote CVS Verzeichnisse
Erstellen von Releases

Einleitung

Dateien wie Programmquellen oder Dokumentationen unterliegen einer hohen Änderungshäufigkeit. Hinzu kommt, daß oftmals viele Dateien in verschiedenen Versionen parallel von mehreren Entwicklern bearbeitet werden. Das Programm CVS unterstützt diese Aufgabe. Diese kleine Ausarbeitung soll neuen oder gelegentlichen Benutzern ohne tiefere Kenntnisse (sog. Dummies) den Umgang mit CVS erleichtern.

Dieser Artikel richtet sich an Anwender von CVS, er bietet keine vollständige Dokumentation, sondern eine Einführung der wichtigsten Konzepte und Befehle.

Motivation

Ein typisches Phänomen bei Quelldateien zu Programmen oder Dokumentationen ist, daß sie über längere Zeiträume von verschiedenen Entwicklern immer wieder in meist kleinerem Umfang geändert werden. Hierbei hat man verschiedene Anforderungen: So sollen Änderungen, z.B. Löschungen von Textabschnitten, rückgängig gemacht werden können. Oder es soll die Fassung vom 29. April 2000 rekonstruiert werden. Oder es soll der Änderungsverlauf nachvollziehbar sein, warum also wann von wem welche Änderungen durchgeführt wurden.

Es sind also verschiedene Fassungen oder Versionen einer Datei und die Zusammenhänge zwischen ihnen zu berücksichtigen. Hierzu können natürlich laufend Kopien der entsprechenden Dateien erstellt werden. Ein besserer Ansatz ist jedoch der Einsatz eines Versionsverwaltungssystems, welches für solche Aufgaben entworfen wurde. Dieses macht sich die inkrementelle Natur des Vorgangs zunutze, indem es nur die Änderungen zwischen den Versionen archiviert. Versionen werden über sogenannte Versionsnummern identifiziert.

Die Situation wird verschärft, wenn gleichzeitig mehrere Entwickler an einem Projekt arbeiten, das aus vielen, vielleicht Hunderten von Dateien besteht. Einerseits ist dafür das unabhängige Arbeiten zu gewährleisten, andererseits dürfen Änderungen nicht verloren gehen.

Der Ansatz von CVS

CVS ("Concurrent Versions System") ist ein solches Versionsverwaltungssystem, welches als GNU-Produkt allgemein verfügbar ist und speziell auch mit großen Projekten und vielen Dateien und Entwicklern zurechtkommt.

Für CVS ist ein Projekt einfach ein UNIX-Dateibaum mit den dazugehörigen Dateien. An zentraler Stelle, dem sog. Repository cvsroot, werden alle Fassungen der einzelnen Dateien zusammen mit den Änderungsprotokollen archiviert. Üblicherweise werden nur Quellen CVS unterstellt, nicht jedoch daraus abgeleitete Dateien, die beispielsweise beim Übersetzen von C (*.o), Java (*.class*) oder LaTeX (*.dvi) anfallen.

Einzelne Benutzer besitzen jeweils lokale Kopien, die sie wie gewohnt bearbeiten können, insbesondere unabhängig von anderen Entwicklern. Es werden also keine Locking-Mechanismen benutzt.

Nachdem lokale Änderungen ausgetestet sind, werden diese von den Benutzern in das globale Verzeichnis übertragen, wobei CVS Benutzer, Datum etc. geeignet protokolliert. CVS sorgt dafür, daß Änderungen mehrerer Benutzer an der gleichen Datei richtig übernommen werden, sofern sich Änderungen nicht überschneiden. Von CVS kann aber nicht überprüft werden, ob diese Änderungen logisch zusammenpassen, es wird nur syntaktisch auf Kollisionen überprüft. Der einzelne Entwickler übernimmt also bei diesem Vorgang die Verantwortung den anderen Entwicklern gegenüber, daß die Änderungen sinnvoll sind und die Dateien sich in einem vernünftigen Zustand befinden (z.B. sich übersetzen lassen).

Man beachte also: "CVS is not a substitute for developer communication." [P. Cederquist]

Einsatz von CVS

CVS kann zur Verwaltung von beliebigen Dateien benutzt werden, wobei der Schwerpunkt auf Textdateien liegt. Sowohl Texte, die z.B. in HTML oder LaTeX vorliegen, als auch Programmcode in den verschiedensten Sprachen kann somit problemlos verwaltet werden. Die Autoren dieses Artikels benutz(t)en CVS sowohl für umfangreiche Texte, wie Diplomarbeiten, als auch für Webseiten und große Programmpakete. Ein Einsatz von CVS ist sowohl für
einzelne Entwickler als auch für große Projekte mit Hunderten von Entwicklern ratsam.

Innerhalb dieser Projekte haben einige Entwickler Schreibrechte, während der interessierte Rest der Welt über einen anonymen Lesezugriff den Entwicklungsstand des Projekts mitverfolgen und auf den entsprechenden Projekt-Mailinglisten mitdiskutieren kann.

Besonders in der Entwicklung von Open Source Projekten ist CVS das Standardwerkzeug. Die meisten GNU Pakete sind mittlerweile per CVS erreichbar, wie die GNU Compiler Collection (GCC) unter gcc.gnu.org. CVS ist ebenfalls ein Open Source Projekt und wird auch per CVS verwaltet (siehe www.cvshome.org). Desweiteren werden auf Sourceforge mehr als 12.000 verschiedene Softwarepakete mit CVS verwaltet. Projekte wie KDE, Gnome und Mozilla sind auch unter CVS.

Weitere Dokumentation

Ausführliche Hilfe zu CVS gibt es in der Info-Dokumentation. Diese ist entweder durch info cvs oder im Emacs bzw. XEmacs durch C-h i (Einstiegsseite für Info-Dokumentation) erreichbar. Außerdem gibt es noch die Manualpages (man cvs).

Eine kurze Hilfe zu CVS gibt es mittels der Aufrufe

cvs --help
cvs --help-commands

Hilfe zu einzelnen Kommands gibt es mittels

cvs --help kommando

Das Buch "Open Source Development with CVS" von Karl Fogel (Coriolis Verlag, ISBN 1-57610-490-7) erläutert nicht nur ausführlich CVS, sondern gibt auch eine Einführung in die Entwicklung freier Software mit zahlreichen Tips für das Projektmanagment.

Die Quellen von CVS und weitere Dokumentation ist über die Homepage des CVS Projektes verfügbar.

Die wichtigsten Kommandos

Alle Kommandos von CVS werden als Parameter des UNIX-Programmes cvs angegeben. Es kann jeweils nur ein Kommando angegeben werden, wobei die Reihenfolge der Parameter wichtig ist. In fast allen Fällen werden keine zusätzlichen Optionen gebraucht, der Aufruf ist einfach:

cvs kommando [<filename>]

Wird kein Dateiname übergeben, dann wird das entsprechende Kommando im aktuellen Verzeichnis und in allen Unterverzeichnissen ausgeführt. Der Dateiname darf Pfadinformationen enthalten.

Vorbereitungen

Um bequem CVS verwenden zu können, richtet man am besten zu Anfang die Arbeitsumgebung entsprechend ein.

Umgebungvariablen

Von den vielen von CVS verwendeten Umgebungsvariablen sind im allgemeinen nur drei wichtig: CVSROOT, CVSUMASK und CVSEDITOR. Der Pfad zum globalen CVS-Verzeichnis befindet sich in CVSROOT. Wenn diese Variable nicht gesetzt ist, können einige
CVS-Kommandos, insbesondere import und checkout und init , nicht funktionieren! Alternativ kann auch den Kommandos mit Option -d <verzeichnis> das Verzeichnis mitgeteilt werden. CVSUMASK bestimmt die Maske für die Zugriffsberechtigungen der einzelnen Dateien im globalen Verzeichnis und sollte den Zugriff für die "Gruppe" beinhalten. Mit CVSEDITOR wird schließlich der bei cvs commit aufzurufende Editor festgelegt. Diese Variablen können zum Beispiel in der Datei .bashrc folgendermaßen definiert werden:

export CVSROOT /cvsroot
export CVSUMASK 003
export CVSEDITOR 'emacs -nw'

Konfigurationsdateien

In der Datei .cvsignore werden Muster für die von CVS zu ignorierende Dateinamen aufgenommen. Für Java bieten sich beispielsweise an, die .class-Dateien zu ignorieren. Dies kann entweder über eine globale Datei namens .cvsignore im Homeverzeichnis, oder eine Datei .cvsignore im entsprechenden CVS-Verzeichnis erfolgen.

Für eine globale Datei, legt man in seinem Home-Verzeichnis die Datei .cvsignore mit folgendem Inhalt an:

*.class

Für bestimmte Kommandos ist es sinnvoll, Standardaufrufparameter in die Datei ~/.cvsrc aufzunehmen. Es empfiehlt sich zumindest die Zeile:

update -d

Somit werden neue Verzeichnisse im Repository beim Update nicht ignoriert, sondern in das aktuelle Verzeichnis übernommen.

Arbeitskopie erstellen

Um mit CVS an einem Projekt arbeiten zu können, muß zu Anfang eine Arbeitskopie erstellt werden. Dies ist notwendig, damit CVS später die Zusammenhänge mit der globalen Fassung herstellen kann. Mit dem Kommando

cvs checkout <modulname>

wird im momentanen Verzeichnis eine aktuelle Kopie des entsprechenden Projektes in einem gleichnamigen Unterverzeichnis angelegt (neudeutsch: ausgecheckt).

Dazu muß das Projekt bereits CVS unterstellt worden sein (vgl. Abschnitt "Einrichten eines Projektes").

Änderungen synchronisieren

Arbeiten mehrere Entwickler zusammen, sind die Änderungen regelmäßig abzugleichen. Um dies bei eigenen Dateien mit den Änderungen anderer zu tun, verwendet man das Kommando

cvs update

Damit werden die global erfolgten Änderungen in die eigenen lokalen Kopien übernommen. Hatte man die lokale Kopie nicht geändert, kann dies problemlos geschehen. Andernfalls werden im Falle nicht-überlappender Änderungen die globalen Änderungen integriert, ohne die lokalen zu überschreiben. Kommt es zu Konflikten, weil die gleichen Stellen verändert wurden, werden in der Datei beide Fassungen in folgender Form aufgenommen:

...
<<<<<<< filename
... lokaler Text ...
=======
... globaler Text ...
>>>>>>> 1.3
...

Das Programm gibt hierbei eine entsprechende Warnung aus:

cvs update: Updating .
RCS file: /home/aj/cvsroot/Test/filename,v
retrieving revision 1.2
retrieving revision 1.3

Merging differences between 1.2 and 1.3 into filename
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in filename

Dann sind die entsprechenden Stellen von Hand in Ordnung zu bringen.

Um eigene Änderungen global verfügbar zu machen (neudeutsch: einzuchecken), verwendet man das Kommando commit. Hierbei ist zu unterscheiden, ob dies bei einer einzelnen Datei, einer Dateigruppe oder allen geänderten Dateien erfolgen soll, da alle Änderungen mit der gleichen Änderungsnachricht versehen werden und diese natürlich inhaltlich sinnvoll sein sollen. Um eine einzelne Datei einzuchecken verwendet man folgenden Aufruf:

cvs commit <filename>

Bei mehreren Dateien sind einfach die verschiedenen Namen aufzuführen. Will man hingegen alle Änderungen vornehmen, so verwendet man

cvs commit

Ein Einchecken ist nicht möglich, wenn die globalen Änderungen nicht lokal übernommen und Konflikte nicht entsprechend aufgelöst wurden. Deshalb empfiehlt sich direkt vor einem cvs
commit ein cvs update. CVS gibt aber auch entsprechende Meldungen aus.

Um die Unterschiede zwischen lokaler und globaler Fassung zu bestimmen, kann man den Aufruf

cvs diff <filename>

verwenden. Mit der zusätzlichen Angabe von Versionsnummern lassen sich die Differenzen zwischen beliebigen Fassungen ausgeben:

cvs diff -r1.1 -r1.5 <filename>

Das Kommando cvs commit ruft den in CVSEDITOR spezifizierten Editor auf, mit dem man eine Änderungsnachricht erstellt. Dies ist ein wichtiges Feature für die Verfolgbarkeit von Änderungen: Warum wurde damals dies und das von wem gemacht? Alternativ kann man mit dem Argument -m "Nachricht" eine Kurznachricht direkt über die Kommandozeile übergeben. Die Liste aller dieser Nachrichten kann durch

cvs log <filename>

ausgegeben werden.

Neue Dateien registrieren

Soll in ein bestehendes Projekt eine neue Datei integriert werden, so legt man sie zunächst lokal im vorgesehenen (und bereits ausgecheckten!) Verzeichnis an. Dann merkt man sie mittels

cvs add <filename>

vor. Um sie dann global zu registrieren, erfolgt ein:

cvs commit <filename>

Neue Unterverzeichnisse werden auf die gleiche Weise angelegt.

Dateien löschen

Muß man wirklich Dateien löschen, weil z.B. eine Datei aufgeteilt wurde, so entfernt man sie zunächst lokal mittels rm. Danach ruft man

cvs delete <filename>

zum Vormerken dieser Operation auf. Schließlich erfolgt noch ein

cvs commit <filename>

womit die Aktion auch global ausgeführt wird, die Datei also in diesem Projekt auch unter cvsroot gelöscht wird. CVS hält aber dennoch zur Sicherheit die alte Fassung in einem speziellen Verzeichnis unter cvsroot vor.

Versionsinformationen im Quelltext

CVS gestattet es, Versionsinformationen in der Datei explizit zu machen. Dies geschieht durch besondere Schlüsselwörter im Text, die dann durch das System beim Aus- oder Einchecken geeignet ersetzt werden. Die wichtigsten sind $Author$ für den Autor, $Date$ für das Datum der letzten Version, $Revision$ für die aktuelle Versionsnummer und $Log$ für das komplette Änderungsprotokoll. Eine Zusammenfassung der wichtigsten Informationen bietet $Id$.

Für Programme empfiehlt es sich, die gewünschten Informationen in Kommentaren oder - wenn sie auch im übersetzen Programm noch vorhanden sein sollen - Strings anzulegen. Unter LaTeX
bietet der rcs.sty (zu finden unter ftp://ftp.dante.de/tex-archive/macros/latex/contrib/supported/rcs/) einen komfortablen Zugriff auf diese Informationen.

Handhabung aus dem Emacs/XEmacs heraus

Emacs und XEmacs unterstützen seit den neueren Versionen über VC (version control) direkt auch CVS, allerdings vorzugsweise auf Dateiebene. Das wichtigste Kommando, das eigentlich immer das "Richtige" macht, ist C-x v v. Ansonsten kann man VC auch über das Menü Tools ansprechen.

Ergänzungen

Die in diesem Abschnitt erwähnten Kommandos sind für den täglichen Gebrauch von CVS nicht so wichtig.

Einrichten eines globalen CVS-Verzeichnisses

Das globale CVS-Verzeichnis für das Repository wird nach Setzen der Umgebungsvariable CVSROOT durch

cvs init

angelegt und initialisiert. Dies muß vor allen anderen Aktionen erfolgen.

Einrichten eines Projektes

Unter dem globalen Verzeichnis können mehrere Projekte untergebracht werden. In diesem Zusammenhang ist für CVS ein Projekt ein Verzeichnisbaum. Um einen bestehenden Verzeichnisbaum als Projekt unter die Kontrolle von CVS zu stellen, wechselt man in die oberste Ebene des bestehenden Verzeichnisbaumes und führt

cvs import <modulname> <vendor-tag> <release-tag>

aus. Hierbei gibt <modulname> den Namen des Wurzelverzeichnisses des neuen Projektes an, darunter wird der komplette Baum im globalen Verzeichnis kopiert und bleibt lokal unverändert. Soll ein neues Projekt gestartet werden, zu dem noch keine Dateien existieren, legt man zunächst ein neues, leeres Verzeichnis an, wechselt hinein und führt dann cvs import aus. <vendor-tag> und <release-tag> sind Namen, die diesen speziellen Import kennzeichnen und können normalerweise auf Dummy-Werte gesetzt werden.

Achtung: Um hinterher das Projekt unter CVS zu bearbeiten, ist es unbedingt notwendig, es mit:

cvs checkout <modulname>

neu an geeigneter Stelle auszuchecken.

Lokale und Remote CVS Verzeichnisse

Für das Aufsetzen von CVS gibt es verschiedene Möglichkeiten. Im allgemeinen hat die CVSROOT-Variable folgendes Format::METHODE:BENUTZER@RECHNER:/cvs/wurzel/verzeichnis, wobei entsprechende Defaults benutzt werden, falls METHODE, BENUTZER@ oder BENUTZER@RECHNER ausgelassen werden.

Die erste Methode (als "local" bezeichnet) ist ein Zugriff auf ein lokales Verzeichnis, auf das alle Entwickler zugreifen können (evtl. per NFS im lokalen Netz). Die CVSROOT-Variable wird so beispielsweise auf den Wert :local:/cvsroot oder alternativ (das :local: ist optional) auf /cvsroot gesetzt.

Für Zugriff auf CVS Verzeichnisse auf anderen Rechnern kann mittels eines speziellen CVS-Servers oder per rsh bzw. ssh zugegriffen werden. Bei wenigen Entwicklern oder bei einem anonymen Zugriff wird der CVS-Server bevorzugt. Als Methode wird pserver benutzt, so daß CVSROOT z.B. auf :pserver:anoncvs@anoncvs.cygnus.com:/cvs/gcc gesetzt wird.

Beim Zugriff per rsh wird als Methode ext benutzt. Wird anstelle von rsh ein verschlüsselter Zugang mit ssh gewünscht (dies ist die normale Konfiguration für Entwickler von Open-Source Projekten mit Schreibzugriff), so muß die Umgebungsvariable CVS_RSH auf ssh gesetzt werden. CVSROOT hat dann beispielsweise den Wert :ext:cvs.x86-64.org:/cvsroot.

Erstellen von Releases

Ein Release ist ein (konsistenter) Schnappschuß eines kompletten Projektes, der später jederzeit rekonstruierbar sein soll. Es bietet sich an, zumindest nach den einzelnen abgeschlossenen Entwicklungsphasen eines Projektes jeweils einen Release zu erstellen. Dies ist deshalb nicht trivial, da zu dem Zeitpunkt beispielsweise Datei-1 die aktuelle Versionsnummer 1.17 besitzt, während Datei-2 vielleicht 1.78 hat. Hinzu kommt, daß zu einem
späteren Zeitpunkt einzelne Dateien hinzugefügt oder gelöscht werden können. Releases werden nicht durch ein Nummernschema, sondern durch symbolische Namen bezeichnet, wie alpha beta, Spezielle-Fassung-fuer-Bernd etc.

Ein Release wird erstellt durch:

cvs tag <release>

Um einen gegebenen Release eines Projektes auszuchecken, führt man ein

cvs checkout -r <release> <modulname>

aus.

:
Wer ist online?
<% VisitorName = request.cookies("name") If VisitorName ="" then %>Name: Besucher.
Online: <%= Application("ActiveUsers") %> aktive User. <% End if If VisitorName <> "" then %> <% user = Request.Cookies("name") %>Name: <%=user%>.
Online: <%= Application("ActiveUsers") %> aktive User. <% End if %>
Login | Logout
Monitoring:
Benachrichtigen bei Änderungen:

Literaturhinweise:
Open Sources
von Chris DiBona, Sam Ockman und Mark Stone (Hrsg.)
Open Sources (Buchcover)
The Cathedral & the Bazaar
von Eric S. Raymond
The Cathedral and the Bazaar (Buchcover)
Kefk Network:
Thematisch verwandte Subsites:
Apple, BSD, GNU/Linux, Open Content, Recht, Research, Software, Windows. Wissen.
Kefk Network Home
Hacker Emblem glider.png (55x55 -- 724 bytes)

 


URL: http://www.kefk.net/Open_Source/Projekte/CVS/dummies.asp.
Translate this page with Google to 
 
  Website: About | Index | Inhalt | Site Map | Suchen | Wer ist online? | What's new?.
Related Sites: BSD | GNU/Linux | Windows | Software.
 
Ergänzungen, Kommentare und Fragen: Kontakt | Foren | Wiki.
E-Mail: echo "asb at keNOSPAMfk.net"| sed -e "s/ at /@/" -e "s/NOSPAM//".
Copyright | Danksagung | Impressum.