CVS-Benutzung für COSY-11-Mitglieder

Vorbemerkungen

Das hier soll keine allgemeine Einführung in die komplexe Welt des CVS sein, sondern nur eine Kurzanleitung zum Einstieg, ohne erst drei Tage Manual lesen zu müssen. Eine ausführliche Anleitung ist in

Version Management with CVS von Per Cederqvist et al.

zu finden, für weitergehende Informationssuche sei die Homepage von

Cyclic Software

empfohlen.

CVS (Concurrent Versions System) wird bei COSY-11 für die Verwaltung der Quelltexte von EVD und DA verwendet. CVS erlaubt es, daß mehrere Leute gleichzeitig Änderungen an Software (oder eigentlich an beliebigen Texten) vornehmen, ohne daß einer die Änderungen eines anderen wieder rückgängig macht. Zu diesem Zweck gibt es ein zentrales "repository", in dem alle aktuellen und früheren Versionen verwaltet werden. Um mit (oder an) den dort lagernden Quelltexten arbeiten zu können, muß man sich eine bestimmte Version (meist die aktuelle) in ein "working directory" kopieren (checkout). Diese kann man dann verändern und, wenn man sicher ist, daß diese Änderungen auch von allgemeinem Nutzen sind, dem Repository wieder einverleiben (commit), wobei eine neue Version entsteht. Ein anderer, der diese Files auch verändert hat, muß sein Working Directory erst wieder mit dem Repository in Übereinstimmung bringen (update), bevor ein commit möglich ist. Die eigenen Änderungen gehen dabei nicht verloren, sie werden mit den fremden Änderungen zusammengebaut. Vor dem commit sollte man dann aber prüfen, ob die Änderungen miteinander verträglich sind.

COSY-11 Repository

Das COSY-11-Repository befindet sich auf ikpe1104 in /c11cvs. Dort bitte nur lesen und staunen, jede direkte Änderung ist tödlich.

Zugriffsrechte

Zugriff auf dieses Repository haben alle Benutzer der ikpe1104, die der Gruppe cosy11 angehören. Notwendig ist außerdem eine brauchbare CVS-Installation (Version 1.9 oder so), auf den COSY-11-Rechnern sollte sie vorhanden sein.


Schnellstart

Es gibt nur wenige Dinge, die man anfangs wissen muß, sie seien hier in der nötigen Reihenfolge aufgelistet:


Module und Versionen

Die Namen der einzelnen CVS-Module (Verzeichnisse) sollten für C11-Mitglieder offensichtlich sein, hier nur wenige Bemerkungen dazu:
inc enthät alle Includefiles, die evd und da gemeinsam benötigen;
setup enthät die für evd und da benötigten Setupfiles, dort sollte man ein commit natürlich nur machen, wenn man grundlegende Änderungen eingebaut hat, nicht bei jeder Parameteränderung;
my_da ist für eigene da-Entwicklungen gedacht, deshalb ist dort nur ein "Skelett" eines Makefiles zu finden. Ein commit ist hier nicht erlaubt, wer meint, daß dort weitere Dinge von allgemeinem Interesse untergebracht werden müssen möge sich bei P.W. melden.;
misc ist für diverse Hilfsprogramme kleineren Umfangs gedacht, z. Z. ist hier nur Isabells Auswerteprogramm für Hugo und Marie zu finden.

Im Verzeichnis readme ist neben allen bisher existierenden readme-Files ein File versionen zu finden. Darin steht, welche Versionen von welchen Programmen existieren. Die Versionsbezeichnungen (es müssen keine Zahlen sein) werden von CVS als Tags verwaltet, mit Hilfe dieser Tags kann man eine beliebige ältere Version gewinnen. Beispielsweise würde der Befehl cvs update -r V304 clear_event.c das File clear_event.c der da-Version 304 bereitstellen. Dabei ist jedoch Vorsicht geboten: Ein anschließendes cvs update beschafft nicht wieder die aktuelle Version des Files, da diesem dann ein sogenanntes "sticky tag" anhaftet. Mit cvs update -A wird man es aber wieder los.

Da meist bestimmte Versionen der einzelnen Bibliotheken zusammengehören, ist es empfehlenswert, dafür gemeinsame Tags zu vergeben. Bei einigen Versionen ist das geschehen, wie in der Spalte "common tag" abzulesen ist. Man kann dann z. B. mit dem Befehl cvs co -r Hugo c11 einen Verzeichnisbaum gewinnen, der genau den Status vom 10. Aug 1998 widerspiegelt. Auch hier sind alle Files mit einen "sticky tag" behaftet.

Wenn man die Files verändern will, sollte man das nur mit den neuesten Files tun, also welchen, die ohne 'Tag' ausgecheckt wurden. Im Prinzip kann man auch an älteren Versionen Bugfixes vornehmen, dazu muß man vorher einen 'Branch' erzeugen. Wie man das macht steht nicht hier sondern dort.


Autoconf und Make

Der aufmersame Benutzer wird bemerken, daß dort, wo man einen Makefile erwartet, kein solcher ist, statt dessen gibt es Makefile.in, Makefile.orig, configure.in, configure und andere wunderliche Dinge.
Makefile.orig war mal ein Makefile und existiert nur noch zu Referenzzwecken, er wird nicht verwendet (und nie mehr verändert).
Aus Makefile.in wird von configure ein neuer Makefile erzeugt, configure selbst ist mit Hilfe von autoconf aus configure.in entstanden.
Man muß also einfach ./configure aufrufen, dann bildet sich ein neuer Makefile. Configure versucht dabei, die Pfade zu anderen wichtigen Dingen (Cernlib und so) herauszubekommen. Gelingt das nicht, kann man configure ein paar Hinweise mitgeben, wie man das macht, erklärt configure --help.
Eine genaue Beschreibung von Autoconf findet sich in Autoconf von David MacKenzie.


Aktualisiert: 12. August 1998 von P. Wüstner