Überprüfen Sie /usr/share/doc/cvs/html-cvsclient,
/usr/share/doc/cvs/html-info und
/usr/share/doc/cvsbook mit lynx oder starten Sie
info cvs und man cvs für detaillierte Informationen.
Das folgende Setup erlaubt commit's ins CVS-Repository nur durch ein Mitglied der "src" Gruppe und die Administration des CVS nur durch ein Mitglied der "staff" Gruppe. Dies reduziert die Möglichkeit, den Server versehentlich zu misskonfigurieren.
# cd /var/lib; umask 002; mkdir cvs # [Woody] FSH
# apt-get install cvs cvs-doc cvsbook
# export CVSROOT=/var/lib/cvs
# cd $CVSROOT
# chown root:src . # "staff" um bei neuen Projekten mehr
# zu restriktieren
# chmod 3775 . # bei "staff" statt "src", 2775 verwenden
# cvs -d /var/lib/cvs init # es ist sicherer -d anzugeben
# cd CVSROOT
# chown -R root:staff .
# chmod 2775 .
# touch val-tags
# chmod 664 history val-tags
# chown root:src history val-tags
Das Folgende stellt die Shell-Umgebung für den CVS-Repository-Zugriff ein.
Entfernter nur lesbarer Zugang:
$ export CVSROOT=:pserver:anonymous@cvs.sf.net:/cvsroot/qref
$ cvs login
$ cvs -z3 co qref
Lokaler Zugang von der Shell auf der selben Maschine:
$ export CVSROOT=/var/lib/cvs
Entfernter Zugriff ohne SSH (verwenden Sie das RSH Protokoll in
cvs):
$ export CVSROOT=:pserver:account@cvs.foobar.com:/var/lib/cvs
$ cvs login
Dies ist für Lauschangriffe anfällig.
sshEntfernter Zugriff mit SSH:
$ export CVSROOT=:ext:account@cvs.foobar.com:/var/lib/cvs
oder für SourceForge:
$ export CVSROOT=:ext:account@cvs.sf.net:/cvsroot/qref
Man kann auch RSA Authentifizierung nutzen (Mit weniger Passwörter agieren, Abschnitt 9.5.3), was die Passwortabfrage überflüssig macht.
Für
EINTRAG WERT BEDEUTUNG
Quellbaum: ~/Projekt-x gesamter Quellcode
Projektname: Projekt-x der Name dieses Projekts
Vendor Tag: Hauptzweig Wert für ganzen Zweig
Release Tag: Release-initial Wert für eine spezielle Version
Danach
$ cd ~/Projekt-x # wechseln ins Quellverzeichnis
... Erzeugen des Quellcodes ...
$ cvs import -m "Starte Projekt-x" Projekt-x Hauptzweig Release-initial
$ cd ..; rm -R ~/Projekt-x
Um mit Projekt-x unter Verwendung des lokalen CVS-Repositorys zu arbeiten:
$ cd # ins Arbeitsverzeichnis wechseln
$ cvs co Projekt-x # Quellen aus dem CVS kopieren
$ cd Projekt-x
... ändern des Codes ...
$ cvs diff -u # wie diff -u Repository/ lokal/
$ cvs up -C modifizierte_Datei # Änderungen rückgängig machen
$ cvs ci -m "Änderungen" # sichern der lokalen Quellen
$ vi neue_hinzugefügte_Datei # ... ins CVS
$ cvs add neue_hinzugefügte_Datei
$ cvs ci -m "Neue Datei neue_hinzugefügte_Datei"
$ cvs up # verschmelzen mit der letzten
# Version aus dem CVS
... zum Erzeugen aller neu erstellten Unterverzeichnisse im CVS
... ist "cvs up -d -P" stattdessen zu verwenden
... achten Sie auf Ausgaben, die mit "C Dateiname" starten
... nicht modifizierter Code wird nach `.#Dateiname.Version'
verschoben
... suchen Sie nach "<<<<<<<" und ">>>>>>>" in der Datei
$ cvs tag Release-1 # hinzufügen des Release Tag
... weitere Änderungen ...
$ cvs tag -d Release-1 # entfernen des Release Tag
$ cvs ci -m "mehr Kommentare"
$ cvs tag Release-1 # erneutes hinzufügen des Tag
$ cd # ins Arbeitsverzeichnis wechseln
$ cvs co -r Release-initial -d alt Projekt-x
... Originalversion ins alt Verzeichnis kopieren
$ cd alt
$ cvs tag -b Release-initial-bugfixes # erzeuge Zweig (-b)
... nun kann mit der alten Version gearbeitet werden (Tag=sticky)
$ cvs update -d -P # keine leeren Verz. erstellen
... Quellbaum hat nun den sticky Tag "Release-initial-bugfixes"
... arbeiten in diesem Zweig
$ cvs up -d -P # synchronisieren mit von anderen
# modifizierten Dateien in diesem Zweig
$ cvs ci -m "einchecken in diesen Zweig"
$ cvs update -kk -A -d -P
... entfernen des sticky Tag und Inhalt vergessen
... Aktualisierung des Haupt"trunk" ohne Schlüsselwortersetzung
$ cvs update -kk -d -P -j Release-initial-bugfixes
... vermengen des Release-initial-bugfixes Zweigs in den
... Haupt"trunk" ohne Schlüsselwortersetzung. Beseitigen Sie
... Konflikte mit einem Editor.
$ cvs ci -m "vermenge Release-initial-bugfixes"
$ cd
$ tar -cvzf Projekt-x-alt.tar.gz alt # Archiv erstellen, -j für bz2
$ cvs release -d alt # lokale Quellen entfernen (optional)
Nette Optionen zur Erinnerung (als erstes Argument von cvs
nutzen):
-n Probelauf, hat keinen Effekt
-t Anzeigen von Mitteilungen zur CVS-Aktivität
Um die letzte Version aus dem CVS zu nutzen, verwenden Sie "tomorrow" (morgen):
$ cvs ex -D tomorrow Modulname
Fügen Sie ein Alias zum Projekt hinzu (lokaler Server):
$ su - admin # ein Mitglied von staff
$ export CVSROOT=/var/lib/cvs
$ cvs co CVSROOT/modules
$ cd CVSROOT
$ echo "px -a Projekt-x" >>modules
$ cvs ci -m "Nun ist px ein Alias für Projekt-x"
$ cvs release -d .
$ exit # oder Strg-D um von su zurückzukehren
$ cvs co -d Projekt px
... auschecken von Projekt-x (Alias: px) aus dem CVS ins
... Verzeichnis Projekt
$ cd Projekt
... Änderungen vornehmen ...
CVS überschreibt nicht die Datei im Repository, sondern ersetzt sie mit einer anderen. Deshalb sind Schreibrechte im Repository Verzeichnis wichtig. Für jedes neue Repository ist Folgendes zu starten, um diese Bedingung zu sichern.
# cd /var/lib/cvs
# chown -R root:src Repository
# chmod -R ug+rwX Repository
# chmod 2775 Repository # wenn nötig, auch bei Unterverzeichnissen
Das ausführbar-Bit einer Datei wird beibehalten beim Checkout. Wann immer Sie Probleme mit dem ausführbar-Recht in ausgecheckten Dateien haben, ändern Sie die Rechte der Datei im CVS-Repository mit dem folgenden Kommando:
# chmod ugo-x Dateiname
Es folgen CVS-Kommandos mit deren Kürzeln.
{add|ad|new} [-k kflag] [-m 'Bemerkung'] Dateien...
{admin|adm|rcs} [rcs-Optionen] Dateien...
{annotate|ann} [Optionen] [Dateien...]
{checkout|co|get} [Optionen] Module...
{commit|ci|com} [-lnR] [-m 'Bemerkung fürs Protokoll' | -f Datei] \
[-r Revision] [Dateien...]
{diff|di|dif} [-kl] [rcsdiff_Optionen] [[-r rev1 | -D Datum1] \
[-r rev2 | -D Datum2]] [Dateien...]
{export|ex|exp} [-flNn] -r rev|-D Datum [-d dir] [-k kflag] Modul...
{history|hi|his} [-report] [-flags] [-options args] [Dateien...]
{import|im|imp} [-options] Repository vendortag releasetag...
{login|logon|lgn}
{log|lo|rlog} [-l] rlog-Optionen [Dateien...]
{rdiff|patch|pa} [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] Module...
{release|re|rel} [-d] Verzeichnisse...
{remove|rm|delete} [-lR] [Dateien...]
{rtag|rt|rfreeze} [-falnR] [-b] [-d] [-r Tag | -D Datum] \
symbolic_tag Module...
{status|st|stat} [-lR] [-v] [Dateien...]
{tag|ta|freeze} [-lR] [-F] [-b] [-d] [-r Tag | -D Datum] [-f] \
symbolic_tag [Dateien...]
{update|up|upd} [-AdflPpR] [-d] [-r Tag|-D Datum] Dateien...
Subversion ist ein Versions-Kontroll-System der nächsten Generation, das einmal CVS ersetzen soll. Die Entwickler betrachten es zur Zeit als im "alpha" Stadium befindlich, aber es ist wahrscheinlich für die meisten Anwendungen stabil genug. Während dies geschrieben wird, ist Subversion nur in Debian unstable verfügbar.
Das subversion-server Meta-Paket hängt von den benötigten Paketen
libapache2-dav-svn und subversion-tools ab, um einen
Server aufzusetzen.
Zur Zeit setzt das subversion Paket kein Repository auf, man muss
es manuell erzeugen. Eine mögliche Stelle für ein Repository ist in
/var/local/repos.
Erzeugen des Verzeichnisses
# mkdir -p /var/local/repos
und der Repository Datenbank:
# svnadmin create /var/local/repos
Nun ist das Repository für den WWW Server schreibbar zu machen:
# chown -R www-data:www-data /var/local/repos
Um den Zugriff auf das Repository mittels Nutzerauthentifizierung zu
ermöglichen, fügen Sie Folgendes zu
/etc/apache2/mods-available/dav_svn.conf hinzu (oder kommentieren
Sie dies aus):
<Location /repos>
DAV svn
SVNPath /var/local/repos
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
Danach erzeugen Sie eine Nutzerauthentifizierungsdatei mit dem Kommando:
htpasswd2 -c /etc/subversion/passwd ein-Nutzer
Starten Sie Apache2 neu und Ihr neues Subversion Repository wird unter der URL http://hostname/repos verfügbar sein.
Die folgenden Abschnitte erklären die Verwendung verschiedener Kommandos in Subversion.
Um ein neues Subversion-Archiv zu erstellen, verwenden Sie Folgendes:
$ cd ~/Projekt # ins Quellcodeverzeichnis wechseln
$ svn import http://localhost/repos Projekt Projektname \
-m "erster Projektimport"
Dies erzeugt ein Verzeichnis namens Projektname im Subversion Repository, das die Projektdateien enthält. Schauen Sie unter http://localhost/repos/, um zu sehen, ob die Datei vorhanden ist.
Arbeiten mit Projekt-y und Subversion:
$ cd # ins Arbeitsverzeichnis wechseln
$ svn co http://localhost/repos/Projekt-y # Quellcode auschecken
$ cd Projekt-y
... Änderungen durchführen ...
$ svn diff # wie diff -u Repository/ lokal/
$ svn revert modifizierte_Datei # Änderungen rückgängig machen
$ svn ci -m "Änderungen" # Änderungen einchecken
$ vi neue_hinzugefügte_Datei
$ svn add neue_hinzugefügte_Datei
$ svn add Verzeichnis1 # alle Dateien unter Verzeichnis1
# rekursiv hinzufügen
$ svn add -N Verzeichnis2 # Verz. nicht rekursiv hinzufügen
$ svn ci -m "neue Dateien hinzugefügt"
$ svn up # vermenge mit neuester Version
# aus Repository
$ svn log # zeige alle eingebrachten Änd.
$ svn copy http://localhost/repos/Projekt-y \
http://localhost/repos/Projekt-y-branch \
-m "erzeuge Zweig von Projekt-y"
$ svn copy http://localhost/repos/Projekt-y \
http://localhost/repos/Proj-y_release1.0 \
-m "Projekt-y 1.0 Release"# fügte release Tag hinzu
... Es ist zu beachten, dass das Erzeugen eines Zweigs und eines
... Tags das selbe ist. Der einzige Unterschied ist, dass Zweige
... "committed" werden, Tags nicht.
... Änderungen im Zweig durchführen ...
$ # vermengen der Kopie des Zweiges mit Hauptkopie
$ svn merge http://localhost/repos/Projekt-y \
http://localhost/repos/Projekt-y-branch
$ svn co -r 4 http://localhost/repos/Projekt-y # Rev. 4 besorgen
Debian-Referenz
CVS, Mon 3. Apr 2005, 22:57:58 UTCosamu@debian.orgtux-master@web.de