Zurück: Vorbereitungen Inhalt: CVS benutzen Weiter: Weiterlaufen
![]() |
Erste Schritte |
Bevor an einem CVS-Projekt gearbeitet werden kann, muß es ausgecheckt werden. Eine Bearbeitung direkt im Repository ist nicht möglich (bzw. sinnvoll).
Ein Projekt wird mit dem Befehl checkout
oder kurz
co
ausgecheckt. Dabei muß mit dem Schalter -d
angegeben werden, welcher CVS-Repository benutzt werden soll.
kai@fREUNd:~$ cvs -d /home/kai/cvsroot/ co xpenguins cvs checkout: Updating xpenguins U xpenguins/AUTHORS U xpenguins/COPYING U xpenguins/ChangeLog U xpenguins/INSTALL U xpenguins/Makefile U xpenguins/README U xpenguins/toon.c U xpenguins/toon.h U xpenguins/vroot.h U xpenguins/xpenguins U xpenguins/xpenguins.1 U xpenguins/xpenguins.c cvs checkout: Updating xpenguins/penguins U xpenguins/penguins/bomber.xpm U xpenguins/penguins/climber.xpm U xpenguins/penguins/def.h U xpenguins/penguins/explosion.xpm U xpenguins/penguins/faller.xpm U xpenguins/penguins/floater.xpm U xpenguins/penguins/tumbler.xpm U xpenguins/penguins/walker.xpm
Anstelle von -d /home/kai/cvsroot
kann auch die Umgebungsvariable
CVSROOT
gesetzt werden. Dies ist jedoch nicht unbedingt nötig, da
CVS in dem ausgecheckten Verzeichnisbaum speichert, welcher Repository genutzt
wird. D.h. wenn man sich in einem ausgecheckten Verzeichnis befindet ist die
Angabe von -d /home/kai/cvsroot
sowiso nicht mehr nötig.
Zu beachten: CVS beachtet Dateirechte und Benutzer und Gruppen nicht!
checkout
-Komando durchgeführt hat.
Wenn man anstatt auf ein lokales auf ein entferntes Repository zugreifen
will, ändert sich eigentlich fast nichts. Lediglich beim
checkout
der Arbeitskopie müssen ein paar andere Schalter
betätigt werden. Danach speichert CVS die Zugriffsmethode in der
Arbeitskopie. D.h. wenn man sich in dem Dateibaum der Arbeitskopie befindet,
muß man den Schalter -d
nicht mehr angeben.
Um per SSH auf einen entfernten Repository zuzugreifen muß zunächst in der
Umgebungsvariable CVS_RSH
gespeichert werden, welches
Remote-Shell Programm benutzt werden soll.
kai@fREUNd:~$ export CVS_RSH=ssh kai@fREUNd:~$
Danach muß beim checkout
wieder der Schalter -d
betätigt werden.
kai@fREUNd:~$ cvs -d :ext:kai@bRUDEr:/var/lib/cvs co cvs cvs server: Updating cvs U cvs/background.png U cvs/ersteschritte.html U cvs/fortsetzung.html U cvs/index.html U cvs/muster.html U cvs/quellen.html U cvs/stolperfallen.html U cvs/timemachine-klein.png U cvs/timemachine.png U cvs/vorbereitungen.html U cvs/vortrag.css U cvs/weiterlaufen.html U cvs/wettrennen.html kai@fREUNd:~$
Die allgemeine Syntax von -d
ist:
:ZUGRIFFSMETHODE:BENUTZER@RECHNER:PFAD_ZUM_CVSVERZEICHNIS
.
ext
steht hier dafür, daß ein externes Programm für die
Verbindung benutzt werden soll. Welches ist in CVS_RSH
gespeichert. Weiter sieht man: ich greife als Benutzer kai
auf den Rechner bRUDEr
auf das Repository
/var/lib/cvs
zu.
Um diese Zugriffsmethode zu aktivieren sind keine Root-Rechte notwendig. Die einzige Voraussetzung ist, das sich das CVS-Binary in dem Pfad des Remote-Shell-Accounts befindet. D.h. man kann auf einem beliebigen Rechner, auf dem man einen Account besitzt, in seinem Home-Verzeichnis einen CVS-Repository anlegen und auf dieses Repository von anderen Rechnern aus zugreifen.
Wie die authentifizierung abläuft bestimmt dabei das Programm, das in
CVS_RSH
angegeben wurde. (In meinem Fall war keine
Passworteingabe nötig, da ich für diesen Rechner einen SSH-Schlüssel
ohne Mantra benutze... bequem, aber eine gewisse Sicherheitslücke.)
Bei dem Zugriff über einen pserver, der natürlich auf dem Remote-Rechner
entsprechend eingerichtet worden sein muß, ist zunächst eine
Authentifizierung per login
notwendig. Danach kann die
Arbeitskopie ausgecheckt werden. CVS legt die Zugriffsmethode (und in diesem
Fall auch das Passwort) wieder in der Arbeitskopie ab, so daß nach dem
checkout
die Zugriffsmethode wiederum nicht mehr angegeben
werden muß. Als ZUGRIFFSMETHODE
muß dieses mal
pserver
gewählt werden.
kai@fREUNd:~$ cvs -d :pserver:anonymous@anoncvs.kde.org:/home/kde login Logging in to :pserver:anonymous@anoncvs.kde.org:2401/home/kde CVS password: kai@fREUNd:~$ cvs -d :pserver:anonymous@anoncvs.kde.org:/home/kde co kdepim/kpilot cvs server: Updating kdepim/kpilot U kdepim/kpilot/.cvsignore U kdepim/kpilot/AUTHORS U kdepim/kpilot/COPYING U kdepim/kpilot/ChangeLog U kdepim/kpilot/INSTALL [...] U kdepim/kpilot/lib/syncAction.cc U kdepim/kpilot/lib/syncAction.h U kdepim/kpilot/lib/uiDialog.cc U kdepim/kpilot/lib/uiDialog.h cvs server: Updating kdepim/kpilot/po cvs server: Updating kdepim/kpilot/po/en cvs server: Updating kdepim/kpilot/po/nl kai@fREUNd:~$
Das Passwort ist hier natürlich von dem pserver abhängig, den man benutzt.
Bei anonymen Zugriff ist es aber in der Regel leer (RETURN
).
Im zweiten Schritt muß hier noch mal -d ...
mit angegeben
werden, da zu diesem Zeitpunkt noch nichts ausgecheckt wurde, also noch
keine Arbeitskopie existiert, in der CVS die Zugriffsmethode abgespeichert
haben könnte.
Nachdem man eine weile an dem Code herumgefummelt hat, fragt man sich meistens,
was man überhaupt alles gemacht hat. Dies erfährt man von CVS mit dem
Komando update
(wie der Name ahnen läßt, macht dieses Komando
noch mehr).
Das Komando arbeitet - wie alle CVS-Komandos - auf allen Dateien in dem aktuellen Verzeichnis und steigt auch in untergeordnete Verzeichnisse ab.
kai@fREUNd:~$ cd xpenguins/ kai@fREUNd:~/xpenguins$ echo "Ich war hier..." >> README kai@fREUNd:~/xpenguins$ echo "/* Sinnloser Text */" >> xpenguins.c kai@fREUNd:~/xpenguins$ echo "/* Sinnloser Text */" >> penguins/def.h kai@fREUNd:~/xpenguins$ cvs up cvs update: Updating . M README M xpenguins.c cvs update: Updating penguins M penguins/def.h kai@fREUNd:~/xpenguins$
Wie man sieht ist der Schalter -p
nicht mehr nötig, da wir uns
nun in einem ausgecheckten Verzeichnis befinden.
Genauere Informationen kann man sich mit dem Komando diff
anzeigen lassen. Auch dieses Komando arbeitet ohne weitere Angaben auf allen
Dateien in dem aktuellen Verzeichnis und den Verzeichnissen, die diesem
untergeordnet sind. Wenn man nur über eine Datei (oder mehrere bestimmte
Dateien) genau wissen will, was man verändert hat, gibt man diese einfach
an. Hier ein Aufruf für ein diff der Änderungen an der Datei
README
:
kai@fREUNd:~/xpenguins$ cvs diff README Index: README =================================================================== RCS file: /home/kai/cvsroot/xpenguins/README,v retrieving revision 1.1.1.1 diff -r1.1.1.1 README 62a63 > Ich war hier... kai@fREUNd:~/xpenguins$
Das CVS-diff
versteht die üblichen diff
-Schalter.
Hier ein Aufruf mit -c
ohne angabe eines bestimmten Files. Es
werden also die diff's gegen alle veränderten Dateien angezeigt:
kai@fREUNd:~/xpenguins$ cvs diff -c cvs diff: Diffing . Index: README =================================================================== RCS file: /home/kai/cvsroot/xpenguins/README,v retrieving revision 1.1.1.1 diff -c -c -r1.1.1.1 README *** README 9 May 2003 17:34:47 -0000 1.1.1.1 --- README 9 May 2003 21:20:31 -0000 *************** *** 60,62 **** --- 60,63 ---- Microsoft Windows and called it `WinPenguins' - visit: http://neomueller.org/~isamu/winpenguins/ + Ich war hier... Index: xpenguins.c =================================================================== RCS file: /home/kai/cvsroot/xpenguins/xpenguins.c,v retrieving revision 1.1.1.1 diff -c -c -r1.1.1.1 xpenguins.c *** xpenguins.c 9 May 2003 17:34:47 -0000 1.1.1.1 --- xpenguins.c 9 May 2003 21:20:40 -0000 *************** *** 423,425 **** --- 423,426 ---- exit(0); } + /* Sinnloser Text */ cvs diff: Diffing penguins Index: penguins/def.h =================================================================== RCS file: /home/kai/cvsroot/xpenguins/penguins/def.h,v retrieving revision 1.1.1.1 diff -c -c -r1.1.1.1 def.h *** penguins/def.h 9 May 2003 17:34:47 -0000 1.1.1.1 --- penguins/def.h 9 May 2003 21:20:44 -0000 *************** *** 50,52 **** --- 50,53 ---- { bomber_xpm, 16, 1, 32, 32, TOON_NOCYCLE }, { explosion_xpm, 1, 1, 64, 64, TOON_NOCYCLE } }; + /* Sinnloser Text */ kai@fREUNd:~/xpenguins$
Stellt man nun fest, das die Änderungen an der Datei README
eigentlich doch überflüssig sind, so kann man diese einfach verwerfen,
indem man die Datei löscht und sich nachher per cvs up
die
alte Version wiederholt:
kai@fREUNd:~/xpenguins$ rm README kai@fREUNd:~/xpenguins$ cvs up cvs update: Updating . cvs update: warning: README was lost U README M xpenguins.c cvs update: Updating penguins M penguins/def.h kai@fREUNd:~/xpenguins$
Das U
vor der Datei README
zeigt an, daß diese
neu aus dem Repository geholt wurde. Das M
vor
xpenguins/def.h
zeigt an, daß hier weiterhin Änderungen in
unserer Arbeitskopie des Projektes vorhanden sind, die noch nicht in das
Repository übertragen wurden.
Nachdem wir uns nun versichert haben, daß alle vorgenommenen Änderung sinnvoll
sind, sollen diese in das Repository übertragen werden.
Dies leistet das Komando checkin
oder kurz ci
.
Auch dieses Komando kann ohne weitere Angaben aufgerufen werden, um alle
Änderungen in das Repository zu übertragen, oder mit einer Liste von Dateien,
wenn nur bestimmte Änderungen übertragen werden sollen.
kai@fREUNd:~/xpenguins$ cvs ci -m "Mehr oder weniger sinnige Änderungen" cvs commit: Examining . cvs commit: Examining penguins Checking in xpenguins.c; /home/kai/cvsroot/xpenguins/xpenguins.c,v <-- xpenguins.c new revision: 1.2; previous revision: 1.1 done Checking in penguins/def.h; /home/kai/cvsroot/xpenguins/penguins/def.h,v <-- def.h new revision: 1.2; previous revision: 1.1 done kai@fREUNd:~/xpenguins$
CVS teilt mit, daß nun in dem Repository neben der vorhergehenden (initialen) Version 1.1 für die beiden Dateien eine neue Version 1.2 erzeugt wurde.
Ohne Angabe von -m "Mehr oder weniger sinnige Änderungen"
würde
der Standard-Editor geöffnet, um eine Checkin-Lognachricht zu erfragen.
Dies sieht dann z.B. so aus:
CVS: ------------------------------------------------------------------ CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: README toon.h CVS: Added Files: CVS: LIESMICH CVS: ------------------------------------------------------------------ ~ ~ ~ ~ 1,0-1 All
CVS listet in einem auskommentierten Bereich die Dateien auf, die durch
den Checkin geändert, hinzugefügt oder gelöscht werden. Es lohnt sich,
nicht einfach alle Dateien einzuchecken, sondern immer die Dateien gemeinsam,
deren Änderungen inhaltlich zusammenhängen. Dann kann man bequem die
Kommentarzeichen (CVS:
) vor den Zeilen entfernen, die die
Änderungen auflisten, und braucht nur noch eine Textnachricht zu ergänzen.
Achtung: Gute Checkin-Logs zu schreiben macht zwar Arbeit, aber auch unheimlich viel Sinn. Sie können später bei der gewissenhaften Vorbereitung einer Zeitreise von unschätzbarem Wert sein!
Wie fügt man nun eine neue Datei zu einem Projekt hinzu? Erzeugen wir
zunächst die Datei und fragen CVS mit dem Komando update,
was es von dieser Datei weiß:
kai@fREUNd:~/xpenguins$ echo "Dies ist der Inhalt" > neu.txt kai@fREUNd:~/xpenguins$ cvs up cvs update: Updating . ? neu.txt cvs update: Updating penguins kai@fREUNd:~/xpenguins$
Wie man sieht, weiß CVS konsequenter weise nichts mit unserer neuen
Datei anzufangen. Wir müssen CVS also mitteilen, daß wir eine neue Datei
erzeugt haben. Dies geschieht mit dem Komando add
:
kai@fREUNd:~/xpenguins$ cvs add neu.txt cvs add: scheduling file `neu.txt' for addition cvs add: use 'cvs commit' to add this file permanently kai@fREUNd:~/xpenguins$
CVS weist uns darauf hin, daß wir das Komando commit
benutzen
müssen, um unsere neue Datei wirklich in das Repository aufzunehmen. Was
hat das zu bedeuten?
Dass add
-Komando arbeitet nur auf der Arbeitskopie des
Projektes. D.h. es vermerkt in einer der Dateien, die in dem Verzeichnis
CVS
zu finden sind, daß unsere neue Datei beim nächsten
Aufruf von commit
in das Repository übertragen werden soll.
An dem Repository verändert unser Aufruf von cvs add
also
nichts! Wenn wir die neue Datei löschen, bevor wir cvs ci
aufrufen, ist sie unwiederbringlich verloren!
kai@fREUNd:~/xpenguins$ cvs ci -m "Neue Datei hinzugefügt" cvs commit: Examining . cvs commit: Examining penguins RCS file: /home/kai/cvsroot/xpenguins/neu.txt,v done Checking in neu.txt; /home/kai/cvsroot/xpenguins/neu.txt,v <-- neu.txt initial revision: 1.1 done kai@fREUNd:~/xpenguins$
Jetzt erst wurde die Datei in das Repository übertragen und erhält die initiale Version 1.1.
Oben haben wir bereits gesehen, daß eine gelöschte
Datei durch den nächsten Aufruf von cvs up
wiederhergestellt
wird. Auch um Dateien aus einem Projekt zu löschen sind also mehrere Schritte
nötig:
Um die Datei neu.txt
wieder zu löschen müssen also folgende
Schritte durchgeführt werden:
kai@fREUNd:~/xpenguins$ rm neu.txt kai@fREUNd:~/xpenguins$ cvs rm neu.txt cvs remove: scheduling `neu.txt' for removal cvs remove: use 'cvs commit' to remove this file permanently kai@fREUNd:~/xpenguins$ cvs ci -m "Datei neu.txt wieder gelöscht." cvs commit: Examining . cvs commit: Examining penguins Removing neu.txt; /home/kai/cvsroot/xpenguins/neu.txt,v <-- neu.txt new revision: delete; previous revision: 1.1 done kai@fREUNd:~/xpenguins$
NEIN!
Auf den ersten Blick mag z.B. das löschen oder hinzufügen von Dateien zu einem CVS-Projekt etwas umständlich erscheinen. Ein paar Worte zum Konzept von CVS sollen daher klarstellen, daß es sich hier nicht um einen Design-Fehler handelt, sondern um eine konsequente Implementation der gewünschten Funktion.
CVS trennt scharf zwischen dem Repository und der Arbeitskopie, die sich
ein Benutzer aus diesem Repository besorgt hat. Für den Benutzer ist immer
nur seine Arbeitskopie zugänglich. Änderungen die er hier vornimmt, bleiben
lokal, bis er sie explizit per checkin
an das Repository
überträgt. Dies hat mehrere entscheidende Vorteile:
Um diese Vorteile zu erreichen kann CVS natürlich nicht einfach irgendwelche Dateien im Repository löschen oder erzeugen, wenn der Benutzer dies in seiner Arbeitskopie tut. CVS kann ja nicht unterscheiden, ob diese Änderungen aus der Sicht des Benutzers sinnvoll und dauerhaft sind, oder bloß experimentellen Charakter haben.
Zurück: Vorbereitungen Inhalt: CVS benutzen Weiter: Weiterlaufen