Mini-Howto

Außer der man-Page gibt es auch eine info-Seite zu cvs: info cvs

Generell nette Parameter für cvs (werden weiter unten nicht immer wieder wiederholt):

-z3 = gzip-Kompression verwenden (weniger Traffic, aber mehr CPU-Last auf CVS-Server)

-Q = leise - nur Fehlermeldungen ausgeben

Environment:

$ export CVS_RSH=ssh

Damit wird dann die Kommunikation verschlüsselt, wichtig v.a. für non-anonymous Accounts.

Einmalig den kompletten Source holen

Als erstes besorgt man sich mal nen kompletten CVS-Checkout des Wunschprojekts, das geht so:

# erstmal ein neues (temporäres) Verzeichnis anlegen:
$ mkdir ~/egal ; cd ~/egal

# dann beim CVS-Server anmelden (bei der Passwort-Frage einfach Enter drücken, also kein Passwort)
$ cvs -d:pserver:anonymous@cvs.egal.de:/cvsroot/egal login

# dann eine komplette Arbeitskopie der Sourcen "auschecken" (checkout, kurz co):
$ cvs -z3 -d:pserver:anonymous@cvs.egal.de:/cvsroot/egal co .

In jedem Verzeichnis unter CVS-Kontrolle gibt es ein Unterverzeichnis "CVS".

Dort liegen für CVS wichtige Informationen, z.B. in der Datei "Root" steht der CVS-Root drin, ebenso Methode (pserver), Login (hier: anonymous), CVS-Server und der Anfang vom Pfad dort. In der Datei "Repository" steht der Rest vom Pfad dort.

Deshalb muss man die o.g. etwas "längeren" CVS-Aufrufe auch nur das erste Mal machen, ab dann "weiß" CVS, was es wo wie kriegt.

lokale CVS-Kopie aktuell halten

Angenommen wir wollen xxx mal wieder auf den aktuellen Stand bringen:

$ cd ~/egal/xxx

# Updates holen/einbinden:
$ cvs update

CVS holt sich dann aus ./CVS/Root die restlichen Informationen, stellt die Differenzen zwischen CVS-Server und lokaler Kopie fest und versucht auch gleich, die Unterschiede einzuarbeiten. Wenn man selbst Änderungen gemacht hatte, werden Sicherheitskopien angelegt (Filenamen mit .#<filename>-<alteversion>, sichtbar mit ls -a).

Falls es Konflikte gab, findet man nachher im Sourcecode Stellen, die in <<<<<<<<<<<<<<<<<< und >>>>>>>>>>>>>>>>> eingerahmt sind, dort muss man dann manuell nachhelfen und die Konflikte lösen.

eigene Änderungen auf den CVS-Server hochladen

Hierzu braucht mal erstmal nen CVS-Account mit mehr Rechten. "anonymous" darf nur lesen, aber nicht schreiben.

Danach sollte man folgendes beachten:

In ./CVS/Root steht immer noch "anonymous" drin - ändern!

Ebenso sollte man eine Environment-Variable mit "export CVS_RSH=ssh" setzen, damit ssh verwendet wird.

Bevor man was "commit"ed, sollte man es erst "update"n, sonst geht es wegen Konflikten möglicherweise nicht.

Also erst lokale Kopie updaten, Konflikte (falls vorhanden) lösen, kompilieren, testen.

Wenn Test OK und nichts anderes "kaputtgemacht" wurde, dann kurz vor dem commit nochmal kurz updaten, Konflikte?, kompilieren, kurzer Test und dann:

$ cd ~/egal/xxx
$ # cvs login (falls noch nicht erfolgt - bei ssh nicht nötig)

# eine geänderte Datei hochladen:
$ cvs commit test.c

oder

# committet alle Änderungen im aktuellen Verzeichnis:
$ cvs commit

CVS fragt dann einen Kommentar ab, den man sinnvoll ausfüllen sollte - damit wissen die anderen Entwickler, was man geändert hat. Der Name des Entwicklers wird automatisch ergänzt, ebenso eine neue Versionsnummer und ein Timestamp.

Das war's. Die lokale modifizierte test.c ist danach auf dem CVS-Server.

Arbeiten mit Branches

Branches sind Verzweigungen in der Entwicklungslinie in einem CVS-Repository.

  1. Auschecken: cvs co
  2. Branch im Repository erzeugen: cvs tag -b branchname
  3. Working Directory auf den Branch umstellen: cvs up -r branchname
  4. Änderungsschleife
    1. Änderungsschleife
      1. Änderungen machen: vi
      2. In den Branch committen: cvs ci
    2. Mit der Hauptlinie synchronisieren: cvs up -kk -j HEAD
      • -kk verhindert unnötige Konflikte auf Zeilen mit Keywords (wie z.B. revision) - nicht verwenden, wenn Binärfiles im Repository sind!
    Patches gegen HEAD kriegt man leider nicht so einfach:
    • man gibt die Revisionsnummer von HEAD an, ist bei mehreren Dateien aber ziemlich unbequem
    • man erzegut die diffs ohne working directory: cvs rdiff -u -r HEAD -r branchname modul

    • man tagged HEAD und erzeugt ein diff dagegen: cvs rtag -r HEAD diffpunkt modul; cvs diff -u -r diffpunkt

      • den tag kann man später auch wieder löschen (und neu setzen) cvs rtag -d diffpunkt modul

Alternativer Weg mit eigenem Repository

  1. "Original" auschecken: cvs co - oder gleich per cvs export -d now oder cvs export -r <tag>

  2. In eigenes Repository importieren: cvs import meinmodul ORIGINAL ORIGINAL_1_0
  3. Working Directory auschecken: cvs co meinmodul
  4. Änderungsschleife
    1. Änderungsschleife
      1. Änderungen machen: vi
      2. Commiten: cvs ci
    2. Original updaten: cvs up
    3. und importieren: cvs import meinmodul ORIGINAL ORIGINAL_1.1
    4. mit der eigenen Entwicklungslinie abgleichen: cvs up -j ORIGINAL
      • wichtig: nach jedem Abgleich einen Tag setzen, z.B. merge1_from_ORIGINAL_to_trunk
      • dann können beim nächsten Abgleich nur die Differenzen, die seither hinzugekommen sind, genommen werden: cvs up -j merge1_from_ORIGINAL_to_trunk -j ORIGINAL

cvs/MiniHowTo (zuletzt geändert am 2007-12-23 22:45:14 durch localhost)