CVS-Verwendung im Projekt

Grundidee

CVS (Concurrent Versions System) dient der Datensynchronisation und -archivierung innerhalb großer Entwicklergruppen. Zu diesem Zweck wird ein zentrales Repository gepflegt, in dem aktuelle und alte Versionen der gemeinsam genutzten Dateien hinterlegt werden.

Jeder Entwickler arbeitet auf einer lokalen Kopie der im Repository hinterlegten Dateien. Das erstmalige Anlegen der lokalen Kopie passiert beim checkout. Im Laufe des Projektes muss jeder Entwickler seine lokale Kopie mit dem Repository abgleichen, er führt ein update durch. Änderungen kann ein Entwickler mittels commit von seiner lokalen Kopie in das Repository übertragen.

Beim Abgleichen und Übertragen behandelt CVS nur Dateien, die bereits im Repository bekannt sind. Neue Dateien müssen daher extra mit add angemeldet werden, ebenso wie inzwischen überflüssige Dateien mittels remove abgemeldet werden können. Bestimmte Dateitypen (die an der Endung erkannt werden, z.B. *.class, *.bak oder *~) werden standardmäßig ignoriert.

Richtlinien

• Jeglicher Quellcode (Klassen, Netze und Wissensbasen), der zur Ausführung der Agenten benötigt wird, sollte ins CVS-Repository eingecheckt werden. Nur dann steht er allen Projektteilnehmern zur Verfügung.
• Grundsätzlich gehören nur lauffähige Versionen der Dateien ins Repository. Sonst werden alle anderen Teilnehmer behindert, weil sie ihre eigenen Entwicklungen nicht mehr testen können.
• Je öfter ihr einen Zwischenstand eincheckt, desto eher können andere ihn benutzen. Am Ende einer gemeinsamen Programmiersession sollte möglichst immer ein Checkin stehen, damit alle Beteiligten vom Endstand aus weitermachen können.
• Beim Checkin sollten alle zusammengehörigen Änderungen auf einmal eingecheckt werden. Das schließt alle add- und remove-Operationen ein. Betrachtet einen Checkin als Transaktion.
• Generierte Dateien (wie compilierte Klassen, Shadow-Netze oder ähnliches) gehören nicht ins Repository.

Erstmaliges Auschecken (checkout)

legt im aktuellen Verzeichnis das Unterverzeichnis module an und holt alle darin befindlichen Dateien und Unterverzeichnisse aus dem Repository. Unser Modul heißt siedler2.

Dabei muss die Umgebungsvariable CVSROOT auf das verwendete Repository zeigen (z. B. vorher mit export CVSROOT=/home/tgi_7/tgi7/cvs setzen). Bei den anderen CVS-Kommandos ist diese Variable nicht nötig, weil in jedem Arbeitsverzeichnis vermerkt wird, aus welchem Repository die Vorlage stammt.

Späteres Aktualisieren (update)

aktualisiert das aktuelle Verzeichnis und alle Unterverzeichnisse. Dabei werden auch neue Unterverzeichnisse angelegt (Option -d) bzw. alte, inzwischen leere Unterverzeichnisse wieder gelöscht (Option -P).

Am besten auf der obersten Ebene des Moduls ausfüren, also im siedler2-Verzeichnis. Dann werden garantiert alle Änderungen erwischt.

Update aktualisiert nicht nur Dateien in eurem Unterverzeichnis , sondern vergleicht alle Dateien der lokalen Entwicklerkopie mit denen im Repository - die Ergebnisse werden durch Großbuchstaben vor den Dateinamen angezeigt. Eine Erklärung der Buchstaben findet sich weiter unten.

Änderungen einchecken

1. Sicherstellen, dass alles compiliert und funktioniert.
2. Dateien, die ihr löschen wollt (oder schon im Arbeitsverzeichnis gelöscht habt), mit cvs remove kennzeichnen.
3. Ein cvs update durchführen (siehe oben). Dabei werden eventuell von anderen Projektteilnehmern eingecheckte Änderungen ausgecheckt.

   Die großen Buchstaben in der ersten Spalte der Ausgabe des update-Befehls sind wichtig:

   M	Die Datei wurde von Euch geändert und wird beim abschließenden commit eingecheckt werden.
   ?	CVS hat die Datei nicht in seiner Verwaltung. Gegebenenfalls muss sie mit add registriert werden (siehe unten).
   A	Die Datei wurde bereits mit add registriert.
   R	Die Datei wurde bereits mit remove zur Löschung registriert.
   C	Nicht nur ihr, sondern auch jemand anderes hat an dieser Datei Änderungen vorgenommen, so dass ein Konflikt aufgetreten ist. Die entsprechende Datei enthält jetzt Konfliktbereiche (markiert durch viele Kleiner-, Größer- und Gleichzeichen). Ihr müsst diese Bereiche manuell in der Datei bearbeiten, bis wieder etwas Sinvolles herauskommt. Alternativ könnt ihr eure eigenen Änderungen verwerfen, indem ihr die Datei löscht und erneut mit update aktualisiert.

   Wenn eine Warnung der Art "xxx was lost" kommt, hat das update die von euch gelöschte Datei xxx wieder hergestellt. Gegebenenfalls müsst ihr die Datei mit cvs remove löschen (siehe unten).

4. Erneut sicherstellen, dass alles compiliert und funktioniert. Schließlich können Änderungen vom update sich auf euren Code auswirken.
5. Endlich cvs commit ausführen (siehe unten).

Dateien hinzufügen (add)

registriert file für die zukünftige Verwaltung im Repository. Verzeichnisse werden sofort im Repository angelegt, Dateien müssen erst noch durch commit bestätigt werden.

Dateien löschen (remove)

erklärt file für gelöscht. Alte Versionen der Datei bleiben im Repository erhalten. Das Löschen muss erst noch durch commit bestätigt werden.

Der remove-Befehl weigert sich, Dateien zu löschen, die noch im Arbeitsverzeichnis herumliegen. Abhilfe bietet die Option -f, die auch das konventionelle Löschen übernimmt.

Es gibt keinen Weg, Verzeichnisse aus dem Repository zu löschen. Stattdessen wird, wenn alle Dateien im Verzeichnis gelöscht wurden, das leere Arbeitsverzeichnis beim nächsten update -P automatisch entfernt.

Checkin bestätigen (commit)

überträgt alle Änderungen aus dem aktuellen Verzeichnis und allen Unterverzeichnissen ins Repository.

Beim commit muss ein Kommentar angegeben werden, der möglichst sinnvoll die eingecheckten Änderungen beschreibt. Standardmäßig konfrontiert euch CVS mit dem Editor vi (den man mittels :q wieder verlassen kann) zum Eingeben des Kommentars. Um das zu vermeiden, könnt ihr die Umgebungsvariable VISUAL auf den Editor eurer Wahl setzen (z.B. "export VISUAL=emacs", am besten in Eure .bash_login eintragen). Alternativ kann mit der Option -m "message text" der Kommentar auf der Kommandozeile angegeben werden.