|
|
|
 |
Kernstück von CVS ist die Repository (dt. Behälter oder dt.-frz. Repertoire), worin die Quelldateien liegen. Diese Repository wird allerdings nicht direkt bearbeitet. Man legt stattdessen für jeden an einem Projekt beteiligten Entwickler ein eigenes Arbeitsverzeichnis an. Darin kann dieser nun beliebig die Dateien verändern, neue hinzufügen oder einzelne Dateien löschen. Jede Veränderung betrifft vorerst immer nur die lokale Kopie des einzelnen Entwicklers in seinem Arbeitsverzeichnis. Will der Entwickler jetzt seine neu überarbeitete Version in die Repository einspielen, muss diese Version eingecheckt werden. Dazu macht der Entwickler zuvor erst ein Update seiner eigenen Datei(en). Dabei werden nur die Quelldateien übernommen, deren Datum jünger als die eigenen sind, um Widersprüche zu vermeiden. Denn es könnten ja in der Zeit, wo Sie die Datei verändert haben, weitere Programmierer ebenso an der gleichen Datei gearbeitet haben. War das Update erfolgreich, wird die Veränderung in die Repository übertragen. Das nächste Auschecken bzw. Update erfolgt jetzt bei allen anderen Entwicklern aus der eben aktualisierten Version. Einrichten eines Archivs (Repository)Damit Sie den anschließenden Erklärungen auch folgen bzw. dies in der Praxis nachvollziehen können, sei Folgendes gegeben: In Ihrem Arbeitsverzeichnis erstellen Sie ein Verzeichnis namens my_project und darin die Verzeichnisse quellcodes und repository. Im Verzeichnis quellcodes befinden sich folgende Dateien (deren Inhalt hier nicht von Interesse sein soll): $ cd my_project/quellcodes $ ls extra.h funktionen.c main.c Das Verzeichnis repository ist noch leer. Somit liegt folgende Hierarchie im Arbeitsverzeichnis vor: my_project | |-quellcodes | | | |-extra.h | |-funktionen.c | |-main.c | |-resository Wenn Sie diese Gegebenheiten erstellt bzw. erzeugt haben, können Sie die folgenden Beispiele selbst in der Praxis ausführen – was sehr zu empfehlen ist. Das komplette Beispiel wird auf dem lokalen Rechner ausgeführt. In der Praxis wird dies natürlich eher selten der Fall sein, was bedeutet, dass der ganze Vorgang meistens über ein Netzwerk (z. B. Internet) vonstatten geht. Bevor Sie ein Archiv verwenden können, müssen Sie dieses logischerweise erst erstellen. Damit Sie im Verlaufe dieses Kapitels nicht immer mittels $ cvs -d /pfad/zum/cvs Kommando auf das Archiv zugreifen müssen, soll erst die Umgebungsvariable CVSROOT neu gesetzt werden. Damit wird so manches einfacher. Dies erledigen Sie mit dem Kommando: $ setenv CVSROOT /pfad/zum/Archiv oder $ export CVSROOT=/pfad/zum/Archiv
In diesem Fall befindet sich das Projekt im Arbeitsverzeichnis. Somit setzen Sie die Umgebungsvariable mittels $ export CVSROOT=$HOME/my_project/repository $ echo $CVSROOT /home/tot/my_project/repository Eine neues Projekt einrichten (Repository initialisieren)Im nächsten Schritt müssen Sie festlegen, welches Archiv verwaltet werden soll. Dazu muss lediglich die Repository initialisiert werden. Wechseln Sie also in das Verzeichnis, in dem sich das Projekt befindet, und initialisieren Sie die Repository wie folgt: $ cd my_project/repository $ cvs init $ ls CVSROOT Jetzt befindet sich in dem Verzeichnis (repository) ein neues Verzeichnis mit dem Namen CVSROOT. Darin befinden sich u. a. viele verschiedene Hilfsdateien für CVS. Bisher haben Sie allerdings nur eine neue Repository initialisiert – somit müssen Sie im nächsten Schritt die einzelnen Dateien des Projektes unter die Kontrolle von CVS bringen – besser importieren. Dazu müssen Sie wieder im Hauptverzeichnis des Projektes sein, worin sich die Quelldateien befinden. Dank der gesetzten Umgebungsvariablen CVSROOT findet CVS sein Ziel von selbst. $ cd $HOME/my_project/quellcodes $ ls extra.h funktionen.c main.c $ cvs import -m 'Bemerkung' mytest_projekt Wolf alpha N mytest_projekt/extra.h N mytest_projekt/main.c N mytest_projekt/funktionen.c No conflicts created by this import Durch import wird in repository ein Verzeichnis mit dem Namen mytest_projekt erzeugt. Darin befinden sich jetzt sämtliche Archivdateien mit der Endung ,v, die mit zusätzlichen Informationen erweitert wurden. Hätten Sie beim import das Flag -m nicht verwendet, hätte sich für den dazugehörenden Kommentar einen Editor (der in der Umgebungsvariablen $EDITOR spezifiziert ist) geöffnet, worin Sie einen entsprechenden Kommentar (hier nur Bemerkung) hätten schreiben können. Die beiden Angaben Wolf und alpha sind so genannte Vendor- und Release-Tags, die zwar vorgeschrieben sind, aber in diesem Fall noch nicht näher betrachtet werden. Auschecken einer ArbeitskopieJetzt können Sie (endlich) mit der Arbeit an Ihrem Projekt beginnen. Dazu müssen Sie die Quelldateien aus dem CVS-Archiv in einen Arbeitsbereich kopieren. Dies wird mit dem Befehl checkout (oder kurz co) erledigt, womit Sie ein komplettes Verzeichnis und alle darin enthaltenen Dateien aus dem Archiv in das aktuelle Verzeichnis kopieren. $ cd ~ $ cvs checkout mytest_projekt cvs checkout: Updating mytest_projekt U mytest_projekt/extra.h U mytest_projekt/funktionen.c U mytest_projekt/main.c Jetzt befindet sich in Ihrem Arbeitsverzeichnis eine Arbeitskopie desselben Inhalts, den Sie zuvor mit import importiert haben – inklusive eines CVS-Verzeichnisses, in dem die CVS-Informationen für die Versionskontrolle gespeichert werden. Dieses CVS-Verzeichnis finden Sie jetzt in JEDEM Unterverzeichnis; also für jedes Verzeichnis im Projekt ein CVS-Verzeichnis. Dies bedeutet natürlich, dass sich in dem Verzeichnis oder den Verzeichnissen Ihres Projekts kein Verzeichnis mit dem Namen CVS befinden darf. $ ls mytest_projekt CVS extra.h funktionen.c main.c Hierzu auch gleich ein Unterschied zu RCS: Bei CVS müssen die Dateien nicht erst gesperrt werden, sondern stehen gleich zum Arbeiten zur Verfügung. Natürlich ist hier von besonderem Interesse, was sich in diesem CVS-Verzeichnis befindet. Dabei erfahren Sie auch gleich, wie CVS arbeitet. Bestimmt fällt Ihnen eine gewisse Ähnlichkeit zu RCS auf – was ja auch selbstverständlich ist, denn (wie schon erwähnt) CVS verwendet das RCS-System. Der einzige Unterschied (auch das wurde schon erwähnt) liegt darin, dass Sie mit CVS die Fähigkeit haben, ganze Dateibäume zu verwalten. Damit dies realisierbar ist, legt CVS eben ein entsprechendes CVS-Archiv (Verzeichnis) an, das dieselben Dateien, Verzeichnisse und Unterverzeichnisse enthält wie das Projekt selbst; nur dass es sich hier um RCS-Dateien handelt. Bei dem checkout-Befehl, den Sie eben verwendet haben, legt CVS die Verzeichnisse in derselben Struktur an wie im CVS-Archiv. Anschließend werden mit RCS die Dateien anhand der Revision konstruiert und in das Arbeitsverzeichnis kopiert. Durch das Konstruieren der Revision ist es erst möglich, dass der Programmierer auch eine ältere Version des Projektes auschecken kann.
Jetzt folgt ein Blick in das CVS-Verzeichnis des ausgecheckten Projekts: $ ls mytest_projekt/CVS Entries Repository Root Die Datei Root verweist auf das Projekt: $ cat mytest_projekt/CVS/Root /home/tot/my_project/repository In Entries sind die Nummern und Checkout-Zeiten des Projektes gespeichert: $ cat mytest_projekt/CVS/Entries /extra.h/1.1.1.1/Wed Dec 10 01:37:08 2003// /funktionen.c/1.1.1.1/Wed Dec 10 01:37:08 2003// /main.c/1.1.1.1/Wed Dec 10 01:37:08 2003// D Diese sind nötig, damit ein commit (folgt noch) richtig ausgeführt wird. Damit weiß CVS, welche Revision sich im Arbeitsbereich befindet. Die Datei Repository verweist auf ein Projekt innerhalb des Archivs, in dem sich die passenden RCS-Dateien befinden (hier auf: mytest_projekt). $ cat mytest_projekt/CVS/Repository mytest_projekt $ ls repository/mytest_projekt extra.h,v funktionen.c,v main.c,v Würden Sie in Ihrem CVS-Archiv eine Quelldatei entfernen (löschen), dann wird auch hierfür von CVS ein Eintrag gemacht. Diese Dateien befinden sich dann in einem Unterverzeichnis namens Attic. Veränderungen von DateienIm nächsten Schritt können Sie jetzt mit den ausgecheckten Dateien Ihres oder des Projektes arbeiten. In diesem Beispiel soll die Datei funktionen.c verändert werden. $ cd ~/mytest_projekt $ ls CVS extra.h funktionen.c main.c $ vi funktionen.c Was verändert wurde, spielt zum Verständnis keine Rolle. Ich rufe hierbei den Editor vi auf, füge eine Zeile im Quellcode dazu und speichere diese Veränderung ab.
Jetzt wollen Sie noch eine Veränderung einbringen. Doch jetzt kommt es: Sie erhalten einen wichtigen Telefonanruf und müssen alles liegen und stehen lassen. Während dieser Zeit hat sich aber jemand anderes am Code zu schaffen gemacht. Jetzt gilt es natürlich, erst einmal mit der Untersuchung der Veränderung(en) fortzufahren. Untersuchen von VeränderungenUm herauszufinden, welche Datei(en) zuletzt geändert wurde(n), reicht der Befehl update: $ cd ~/mytest_projekt $ cvs update cvs update: Updating . M funktionen.c Die Datei funktionen.c wurde hier verändert. Dies können Sie am M, das für Modified steht, erkennen. Bei den vielen Zeilen Code wollen Sie sicherlich auch wissen, was verändert wurde. Dazu können Sie diff verwenden. $ cvs -Q diff -c
Index: funktionen.c
=================================================================
RCS file: /home/tot/my_project/repository/mytest_projekt/funktionen.c,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 funktionen.c
*** funktionen.c 10 Dec 2003 01:37:08 -0000 1.1.1.1
--- funktionen.c 11 Dec 2003 03:23:51 -0000
***************
*** 1,4 ****
--- 1,5 ----
static void hallo(void)
{
printf("Hallo Welt\n");
+ printf("Heute ist ein schöner Tag\n");
}
Ich denke, klarer geht es nicht mehr. Hier finden Sie mit Index den Namen der Datei, mit RCS file den Ort, wo die RCS-Datei gespeichert wurde, die Version, wann diese erstellt wurde und wann die Änderung gemacht wurde. Die Veränderung sehen Sie anhand des +-Zeichens in der Zeile (hier printf("Heute ist ein schöner Tag\n");). In welcher Zeile die Datei geändert wurde und welche Zeilen hinzugekommen sind, können Sie im folgenden Eintrag lesen: *** 1,4 **** (Start des Kontextes ab Zeile 1, Chunk ist 4 Zeilen lang) --- 1,5 ---- (Start des Kontextes ab Zeile 1, Chunk ist 5 Zeilen lang) Mehr dazu würde jetzt den Rahmen des Kapitels sprengen. Daher seien hierfür die Manual Pages von diff empfohlen.
Natürlich können Sie diff und update auch auf einzelnen Dateien verwenden wie z. B. $ cvs update funktionen.c Veränderungen an das Archiv weitergebenNachdem Sie an Ihrem jüngsten Projekt weitergearbeitet und es verändert haben, wird es Zeit, das Projekt mitsamt seinen Änderungen ins Archiv zurückzulegen. Dazu wird der Befehl commit (oder kurz ci) verwendet. Geben Sie commit ohne einen Dateinamen an, werden alle Quelldateien des Projektes, die verändert wurden, an das Archiv gesendet. $ cvs commit -m 'zusätzliche Textausgabe' cvs commit: Examining . Checking in funktionen.c; /home/tot/my_project/repository/mytest_projekt/funktionen.c,v <-- funktionen.c new revision: 1.2; previous revision: 1.1 done An der Ausführung von commit können Sie erkennen, welche Dateien verändert wurden und somit neu eingecheckt werden (hier funktionen.c). Somit hätte hier auch folgendes commit angegeben werden können: $ cvs commit -m 'zusätzliche Textausgabe' funktionen.c Außerdem können Sie an der Ausgabe auch erkennen, dass aus der Revisionsnummer 1.1 die Revisionsnummer 1.2 geworden ist. Jede Datei im Projekt hat übrigens eine eigene Revisionsnummer. Dabei wird die rechte Stelle der Nummer um eins inkrementiert. Unterschiedliche Revisionsnummern in einem Projekt bedeuten nur, dass eine Datei häufiger als die andere verändert (ein commit gesendet) wurde. Mehrere Programmierer – ein ProjektDa Sie bei CVS – im Gegensatz zu RCS – nicht mit Sperren zu kämpfen haben, kann gleich mit den Arbeiten am ausgecheckten Projekt begonnen werden. Und das bedeutet auch im Gegensatz zu RCS, dass jetzt ohne weiteres mehrere Entwickler gleichzeitig das Projekt oder Teile davon auschecken und verändern können. Zwangsläufig können hierbei Konflikte auftreten, wenn ein Entwickler nach Beendigung des Projektes keinen Abgleich (ein commit) mehr macht bzw. den Abgleich erst nach längerer Zeit macht. Wie die Gruppe von Entwicklern dabei vorgehen muss, soll anhand eines Fallbeispiels erklärt werden. Programmierer Anton und Programmierer Xaver greifen beide auf das CVS-Archiv eines Projekts zu und machen ein checkout.
Programmierer Xaver verändert eine Datei im Projekt und teilt die Veränderung dem CVS-Archiv mittels einem commit mit.
Jetzt kommt Programmierer John und holt sich ebenfalls mit einem checkout das Projekt auf seine Platte.
Programmierer Anton hat jetzt auch eine Datei verändert und will dies mit commit dem Archiv mitteilen. Das commit schlägt fehl, da ja Xaver bereits eine Veränderung eingebracht hat, und somit stimmt die Revisionsnummer von Anton nicht mehr mit dem Archiv überein. Um diesen Umstand zu beheben, muss Anton ein Update seines Arbeitsbereiches machen. Dies erledigt dieser mit dem update-Befehl. $ cvs update Mittels update werden bei Anton alle Daten aktualisiert, die seit seinem letzten checkout verändert wurden.
Jetzt muss Anton natürlich überprüfen, ob seine Veränderung mit der von Xaver übereinstimmt – sprich, keine Konflikte entstehen. Hat Xaver z. B. eine globale Funktion verworfen, die Anton in seiner Veränderung verwendet, muss Anton dies beachten. Es empfiehlt sich im Grunde, immer vor dem commit ein update zu machen. Wenn es keine Probleme bei den Veränderungen gab, kann Anton seine Veränderung ebenfalls dem Archiv mitteilen (commit).
Wenn Xaver jetzt ebenfalls wieder das Projekt auf seiner Platte aktualisieren will, reicht auch hier ein einfaches update. Derselbe Vorgang wie eben beschrieben läuft auch ab, wenn zwei Entwickler dieselbe Datei verändern. Allerdings muss auch hierbei beachtet werden, dass sich die Veränderungen vertragen. Jetzt haben wir ja noch John, der dem Archiv mitteilen will, dass er eine Veränderung eingebracht hat. Währenddessen macht Anton eine status-Abfrage, die wie folgt aussieht: $ cvs status funktionen.c File: funktionen.c Status: Locally Modified Working revision: 1.2 Mon Mar 2 06:35:27 2004 Repository revision: 1.2 /home/anton/my_projects/repository/funktionen.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Mittlerweile hat ein weiterer Programmierer namens Leon die Datei funktionen.c bearbeitet und dies bereits dem Archiv mitgeteilt. Somit wäre die aktuelle Revisionsnummer 1.3. Eine status-Abfrage von John auf seinem lokalen Rechner würde jetzt folgendermaßen aussehen: $ cvs status funktionen.c File: funktionen.c Status: Needs Patch Working revision: 1.2 Mon Mar 2 06:35:27 2004 Repository revision: 1.3 /home/john/my_projects/repository/funktionen.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Damit wüsste John, dass jemand bei der Datei funktionen.c ein commit gemacht hat, die Revisionsnummer im Archiv 1.3 und seine Revisionsnummer 1.2 ist und er somit hinterherhinkt. An der Statuszeile könnte John auch erkennen, dass er einen Patch machen soll. Dabei müsste er lediglich ein update machen und die Änderung mittels patch einarbeiten. John hat jetzt aber weder den status-Befehl noch ein update gestartet – schlimmer noch, er hat in derselben Datei funktionen.c dieselbe Zeile wie Leon verändert. Hier liegt ein ganz klarer Konflikt vor. Diesen Konflikt bemerkt John erst beim nächsten commit, das logischerweise erst einmal fehlschlägt. Also macht er zunächst ein update der Datei funktionen.c: $ cvs update funktionen.c RCS file: /home/john/my_project/repository/funktionen.c,v retrieving revision 1.2 retrieving revision 1.3 Merging differences between 1.2 and 1.3 into funktionen.c rcsmerge: warning: conflicts during merge cvs update: conflicts found in funktionen.c C funktionen.c Es liegt also ein Konflikt vor. Welcher Konflikt das genau ist, kann er feststellen, indem er die Datei funktionen.c in seinem lokalen Arbeitsverzeichnis ansieht. $ cat funktionen.c
void hallo()
{
printf("Hallo Welt\n");
<<<<<< funktionen.c
printf ("Heute ist ein schöner Tag\n");
=======
printf ("Heute ist kein schöner Tag\n");
>>>>>>> 1.3
}
Der folgende Teil entspricht der Veränderung von John: <<<<<< funktionen.c
printf ("Heute ist ein schöner Tag\n");
Getrennt werden diese beiden Veränderungen in derselben Zeile mit: ======= Der untere Teil entspricht der Veränderung der aktuellen Revision 1.3, wie sie im CVS-Archiv vorliegt: printf ("Heute ist kein schöner Tag\n");
>>>>>>> 1.3
Diesen Konflikt müssen Sie nun selbst beseitigen. Meistens handelt es sich allerdings nicht um ein solch stupides Beispiel, so dass eine Rücksprache mit dem Entwickler, der an derselben Zeile wie Sie gearbeitet hat, vonnöten ist, so dass es zu einer Übereinkunft kommen wird. Wobei das mit der Rücksprache auch nicht so einfach zu lösen ist. Der Franzose spricht kein Chinesisch, der Chinese kein Deutsch und der Amerikaner kein Spanisch (o. k., viele sprechen Englisch – aber tun wir mal so, als könnte dies auch niemand). Doch auch dafür gibt es bei CVS einen Weg. Wollen Sie allen mitteilen, dass Sie gerade an der Datei funktionen.c arbeiten, können Sie dies mit dem edit-Befehl machen. $ cvs edit funktionen.c Jetzt werden alle anderen informiert, dass Sie gerade an dieser Datei arbeiten. Voraussetzung dafür ist, dass die anderen Entwickler ebenfalls den edit-Befehl verwenden. Jetzt können sich die Entwickler untereinander absprechen oder warten, bis derjenige, der an dieser Datei arbeitet, diese Veränderung(en) an das Archiv (commit) einsendet. Mit einem commit tragen Sie sich praktisch aus dem edit-Modus aus. Besser noch ist der Befehl watch. Damit tragen Sie sich als ständiger Beobachter ein. Wenn Sie hierbei eine Datei auschecken (checkout), geschieht dies vorerst im Lesemodus. Will der Entwickler diese Datei verändern, muss dieser erst edit eingeben. Durch diese Zwangseingabe erfährt der Entwickler, ob gerade jemand an dieser Datei arbeitet. Dass es funktioniert, beweist die Open Source Community, wo CVS fast 100 % Marktanteil hat (Tendenz fallend). Veränderungen rückgängig machenEs kommt zwar nicht häufig vor, aber manchmal kann es sinnvoll sein, eine Veränderung rückgängig zu machen; sei es nun aus Gründen der Unstabilität des Programms oder aus Eigeninteresse, um eine eigene Version aus einem älteren Release zu machen. Das Rückgängigmachen geschieht auch hier wieder mit dem update-Befehl und dem Flag j für join. $ cat funktionen.c
static void hallo(void)
{
printf("Hallo Welt\n");
printf("Heute ist ein schöner Tag\n");
}
$ cvs update -j 1.2 -j 1.1 funktionen.c
RCS file: /home/tot/my_project/repository/mytest_projekt/funktionen.c,v
retrieving revision 1.2
retrieving revision 1.1
Merging differences between 1.2 and 1.1 into funktionen.c
$ cat funktionen.c
static void hallo(void)
{
printf("Hallo Welt\n");
}
$ cvs update
cvs update: Updating .
M funktionen.c
$ cvs commit -m "Rückgängig zur Version 1.1" funktionen.c
Checking in funktionen.c;
/home/tot/my_project/repository/mytest_projekt/funktionen.c,v <-- funktionen.c
new revision: 1.3; previous revision: 1.2
done
Somit hätten Sie ohne großen Aufwand hier im Beispiel die Version 1.1 von der Datei funktionen.c wiederhergestellt, die allerdings trotzdem eine neue Versionsnummer erhält! Dateien und Verzeichnisse hinzufügen, entfernen oder umbenennenJetzt fehlen Ihnen eigentlich nur noch zwei wichtige Kommandos zu CVS; das wären add und remove (oder kurz rm) zum Hinzufügen bzw. Entfernen von Dateien oder Verzeichnissen. Zuerst soll in unserem aktuellen Projekt ein neues Verzeichnis erstellt werden. $ mkdir include $ cvs add include Directory /home/tot/my_project/repository/mytest_projekt/include added to the repository $ cvs update cvs update: Updating . cvs update: Updating include Bei einem Blick in das neue Verzeichnis finden Sie auch hier ein extra dafür angelegtes CVS-Verzeichnis für das Archiv. Das wurde aber bereits zu Beginn erwähnt. Ein commit entfällt hierbei. In de include-Verzeichnis wollen Sie nun eine neue Headerdatei anlegen, vorausgesetzt, es existiert eine Headerdatei in diesem Verzeichnis. Hier machen Sie es sich mit touch leicht. $ touch include/header.h $ cvs add include/header.h cvs add: scheduling file `incl/header.h' for addition cvs add: use 'cvs commit' to add this file permanently $ cvs commit -m "neue Headerdatei" cvs commit: Examining . cvs commit: Examining incl RCS file: /home/tot/my_project/repository/mytest_projekt/incl/header.h,v done Checking in incl/header.h; /home/tot/my_project/repository/mytest_projekt/incl/header.h,v <-- header.h initial revision: 1.1 done Jetzt können Sie mit dem neu erstellten Verzeichnis und auch mit der neu erstellten Datei – wie mit jedem anderen Verzeichnis bzw. jeder Datei – mit CVS arbeiten. Verändern Sie jetzt z. B. die Headerdatei header.h, gehen Sie auch hier gewöhnlich wie im Beispiel folgt vor: $ cvs update cvs update: Updating . cvs update: Updating include M include/header.h $ cvs commit -m 'Headerdatei verändert' include/header.hChecking in include/header.h;/home/tot/my_project/repository/mytest_projekt/include/header.h,v <-- header.h new revision: 1.2; previous revision: 1.1 done Ebenso einfach ist es auch, eine Datei wieder aus dem CVS-Archiv zu entfernen. Hierbei sind folgende Schritte nötig: $ cd include $ rm header.h $ cvs remove header.h cvs remove: scheduling `header.h' for removal cvs remove: use 'cvs commit' to remove this file permanently $ cvs commit -m 'Headerdatei entfernt' cvs commit: Examining . Removing header.h; /home/tot/my_project/repository/mytest_projekt/include/header.h,v <-- header.h new revision: delete; previous revision: 1.2 done Natürlich muss die Datei, bevor diese aus dem CVS-Archiv entfernt wird, erst aus der Arbeitskopie mittels rm gelöscht werden.
Ebenso einfach ist das Umbenennen von Dateien bzw. Verzeichnissen im CVS-Archiv. Im Beispiel wird die Datei leer.c in voll.c umbenannt: $ mv leer.c voll.c $ cvs remove leer.c cvs remove: scheduling `leer.c' for removal cvs remove: use 'cvs commit' to remove this file permanently $ cvs add voll.c cvs add: scheduling file `voll.c' for addition cvs add: use 'cvs commit' to add this file permanently $ cvs commit -m 'Name leer.c umbenannt in voll.c' cvs commit: Examining . cvs commit: Examining include Removing leer.c; /home/tot/my_project/repository/mytest_projekt/leer.c,v <-- leer.c new revision: delete; previous revision: 1.3 done RCS file: /home/tot/my_project/repository/mytest_projekt/voll.c,v done Checking in voll.c; /home/tot/my_project/repository/mytest_projekt/voll.c,v <-- voll.c initial revision: 1.1 done Sie müssen lediglich die alte Datei in der Arbeitskopie umbenennen (hier mit mv) und diese aus dem CVS-Archiv entfernen (cvs remove), um anschließend die neue Datei hinzufügen (cvs add) zu können. Am Ende führen Sie noch ein commit aus, und Sie haben einen neuen Dateinamen. Bei Verzeichnissen können Sie ähnlich vorgehen. Erstellen Sie zuerst ein neues Verzeichnis, fügen Sie dies mit cvs add zum Vormerken für das Archiv dazu. Kopieren Sie jetzt den Inhalt des alten Verzeichnisnamens in das neue Verzeichnis. Jetzt müssen Sie den Inhalt des alten Verzeichnisses löschen, ehe Sie das alte Verzeichnis komplett löschen können. Teilen Sie jetzt noch mit cvs add die neuen Dateien im neuen Verzeichnis dem CVS mit und führen zu guter Letzt ein commit aus. Zugriff auf ein Remote-VerzeichnisNatürlich trifft der Anwendungsfall, wie im Beispiel, in dem sich das Arbeitsverzeichnis auf einem lokalen Rechner befindet, recht selten zu. Gerade in der freien Software (KDE, GNOME, Mozilla usw.) befindet sich die so genannte Repository irgendwo auf einem entfernten CVS-Server. Hier hat man mehrere Zugriffsmöglichkeiten. Entweder verfügt der User über einen eigenen Login auf dem Remote-Rechner via rsh oder ssh. Hierfür muss allerdings die CVS_RSH-Umgebungsvariable angepasst werden. Oder es besteht die Möglichkeit, eine von CVS portierte rsh-Implementierung zu verwenden. Hierbei muss die bereits bekannte Umgebungsvariable CVSROOT angepasst werden. Sind alle Angaben angepasst worden, erfolgt ein Auschecken der Dateien ähnlich wie auf dem lokalen Rechner. Es muss hierbei lediglich ein etwas längerer Pfad zum Archiv angegeben werden. Zuerst erfolgt die Zugriffsmethode, welche von beiden Seiten mit einem Doppelpunkt abgetrennt wird. Anschließend folgen der Benutzername und der Servername, die mit einem @-Zeichen zusammengesetzt werden – gefolgt von einem weiteren Doppelpunkt als Trenner. Am Ende folgt dann der Pfad des Archivverzeichnisses auf dem Server. Als Beispiel folgt hierzu eine durch Passwort authentisierte Server-Zugriffsmethode (kurz pserver): $ cvs -d :pserver:wolf@cvs.pronix.de:/usr/local/cvsroot login (Logging in to wolf@cvs.pronix.de) CVS password: ******** Für mehr Details (in der Praxis) bezüglich des Zugriffs auf ein Remote-Verzeichnis seien die Dokumentation zu CVS oder auch ein Blick auf die Buch-CD empfohlen. Grafische FrontendsWer die Open-Source-Entwicklergemeinde kennt, weiß, dass es immer das eine oder andere grafische Frontend für ein Konsolen-Tool gibt. Ich möchte hier gar nicht auf die einzelnen Frontends eingehen, sondern nur auf die einzelnen Tools hinweisen. Zwei interessante Frontends stehen Ihnen mit jCVS – ein Java-basierter Client – und tkCVS – ein Tk-basiertes grafisches CVS-Interface – zur Verfügung. Als Web-Frontend wäre cvsweb, ein in Perl geschriebener CVS-Client, sehr zu empfehlen, zu dem es auch zusätzlich einige nützliche kleine Skripte gibt. Geht es Ihnen allerdings darum, die ganze Funktionsvielfalt von CVS auszunutzen, dann werden Sie mit dem Java-basierten Client jCVS am besten beraten sein (abgesehen von der Kommandozeile).
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright © Rheinwerk Verlag GmbH 2006
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich
ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen,
wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist
urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der
Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und
Verarbeitung in elektronischen Systemen.
