Zurück: Vorbereitungen Inhalt: CVS benutzen Weiter: Weiterlaufen

Erste Schritte

Ein Projekt auschecken (checkout)

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!

Die Dateien in einem ausgecheckten CVS-Projekt gehören immer dem Benutzer, der das checkout-Komando durchgeführt hat.
Die Dateirechte in dem ausgecheckten Projekt stehen in keinem Zusammenhang mit den Dateirechten in dem Verzeichnisses, das importiert wurde (Ausnahme: in dem Importierten Verzeichnis ausführbare Dateien werden auch in der später ausgecheckten Kopie ausführbar sein.)

Zugriff auf fremde Quellen (login und checkout)

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.

Zugriff per SSH

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.)

Zugriff per pserver

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.

Was habe ich bloß getan?? (update und diff)

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$

Änderungen verwerfen (update)

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.

Änderungen in das Repository übertragen (checkin)

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!

Eine neue Datei hinzugügen (add)

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.


Eine Datei entfernen (rm)

 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:


 Datei löschen
 CVS mitteilen, daß die Datei gelöscht wurde
 Änderungen an das Repository übertragen


 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$ 


Das ist doch alles viel zu umständlich, oder?
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:


 
   Ein Benutzer kann sich eine Arbeitskopie von einem Server besorgen und
   kann dann ohne Kontakt zu Server an dieser arbeiten. Ein Kontakt zum
   Server ist erst dann wieder nötig, wenn er seine Ergebnisse in das 
   Repository übertragen will.
 
 
   Der Benutzer hat absolute Kontrolle darüber, welche Änderungen er
   letztendlich in den Repository überträgt. Sprich: er kann in seiner
   Arbeitskopie herumsauen, wie er will, ohne Angst haben zu müssen, unsinnige
   Änderungen in das Repository zu übertragen.
 
 
   Als Folge aus dem letzten Punkt, kann sich der Benutzer jederzeit 
   eine klare Übersicht darüber verschaffen, welche Änderungen er in 
   seiner Arbeitskopie gegenüber dem aktuellen Stand des Repository
   (oder natürlich jedem beliebigen Stand des Repositorys) vorgenommen
   hat.
 


 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