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:
- CVSROOT
Als erstes benötigt man eine Umgebungsvariable namens CVSROOT, sie sollte den Wert :pserver:$LOGNAME@ikpe1104.ikp.kfa-juelich.de:/c11cvs enthalten.
$LOGNAME steht dabei für den eigenen Loginnamen (auf der ikpe1104), statt ikpe1104.ikp.kfa-juelich.de reicht innerhalb des Forschungszentrums auch ikpe1104.
Auf den COSY-11-Alphas kann es sein, daß sie (die Variable) bereits existiert, mit printenv CVSROOT oder echo $CVSROOT kann man das prüfen. Existiert sie nicht, muß man sie erzeugen, das Verfahren ist abhängig von der shell, die man gerade benutzt:
In csh-Abkömmlingen funktioniert
setenv CVSROOT :pserver:$LOGNAME@ikpe1104:/c11cvs
in sh-Abkömmlingen ist
CVSROOT=:pserver:$LOGNAME@ikpe1104:/c11cvs
gefolgt von
export CVSROOT
notwendig.
- cvs login
Als nächstes muß man sich dem CVS-Server gegenüber ausweisen (mit Hilfe eines Paßwortes). Man tut dies mit dem Befehl cvs login. Nach dem Prompt (CVS password:) muß man das Paßwort, das man auf der ikpe1104 verwendet, eingeben.
Dieses cvs login ist von jedem Rechner aus nur einmal erforderlich, die noetigen Informationen werden in $HOME/.cvspass gespeichert.
- cvs checkout
Dann wechselt man in das Verzeichnis, das man als "Working Directory" auserkoren hat und kann sich eine Kopie der nötigen Files besorgen. Der Befehl dazu lautet
cvs checkout module
Kürzer und völlig identisch ist
cvs co module
module steht für das Softwarepaket, das man haben möchte. Möglich sind:
- evd
- caldc
- da
- field
- mdz
- mdz_c11
- numrec_c
- hbook_c
- readme
- inc
- setup
- my_da
- misc
Man kann auch einfach c11 angeben, dann erhält man ein Verzeichnis c11, das alle anderen Module als Unterverzeichnisse enthält.
Jedes so gewonnene Verzeichnis enthält ein Unterverzeichnis CVS, daß die nötigen Informationen für jegliche weitere Arbeit mit cvs enthält, also bitte nicht beschädigen. Dort steht auch ein Verweis auf das Repository, so daß die Umgebungsvariable CVSROOT nicht mehr gebraucht wird.
- cvs update
Es ist immerhin denkbar, daß auch andere an den Sourcen arbeiten und brauchbare Veränderungen vornehmen. Wenn einer dieser anderen seine Änderungen mit Hilfe von cvs commit (siehe übernächster Punkt) untergebracht hat, kann man daran teilhaben. Das Kommando dazu lautet
cvs update
Es ist in dem Verzeichnis abzusetzen, das die betroffenen Files enthält. Dadurch werden alle Files, die man selbst nicht verändert hat, durch aktuelle Files ersetzt. Files, die man selbst modifiziert hat, aber der andere nicht, bleiben unverändert. Wenn Files von einem selbst und im Repository verändert worden sind, versucht cvs, die Änderungen zu mergen. Meist geht das, wenn es aber mehrere Änderungen in einer Zeile gibt, hat cvs keine Chance mehr. cvs packt dann beide Versionen der fraglichen Zeilen hintereinander, markiert sie mit >>>>>>>>>>> und <<<<<<<<<<<<< und beschimpft den ahnungslosen User. Dieser hat das Problem dann selbst zu lösen, indem er den File wieder editiert und sich für diese oder jene oder eine ganz andere Version entscheidet.
- cvs status
Wenn man vergessen hat, welche Files man geändert hat, ist
cvs status oder cvs status filename
empfehlenswert. Der Status kann folgende Werte annehmen:
- Up-to-date
File im Working Directory und File im Repository sind identisch
- Locally Modified
File im Working Directory ist verändert, File im Repository ist noch der alte
- Needs Checkout
File im Working Directory ist gelöscht worden
- Needs Patch
File im Working Directory ist unverändert, aber File im Repository ist modifiziert
- Needs Merge
File im Working Directory und im Repository sind verändert
- Locally Removed
File im Working Directory ist gelöscht und (via cvs remove) für das Löschen im Repository vorbereitet
- Locally Added
File ist neu und (via cvs add) für das Eintragen im Repository vorbereitet
- Unknown
File ist nicht unter CVS-Kontrolle (oder existiert nicht)
"Needs Checkout" bietet eine schöne Möglichkeit, eigene Änderungen wieder rückgängig zu machen: man löscht den File und beschafft sich mit cvs update filename das Orignal wieder.
- cvs commit
Nachdem man diese oder jene Änderungen vorgenommen hat und der Wunsch, diese Änderungen anderen zugänglich zu machen, ununterdrückbar wird, sollte man ein commit in Betracht ziehen. Tatsächlich sollte man das möglichst bald tun, da im Laufe der Zeit die Wahrscheinlichkeit größer wird, daß andere Änderungen machen, die mit den eigenen Änderungen nicht mehr kompatibel sind. In jedem Fall sollte man sich aber vorher sicher sein, daß die Sourcen kompilierbar sind und zu einem brauchbaren Programm führen.
commit kann nur ausgeführt werden, wenn die eigenen Sourcen alle fremden Änderungen bereits enthalten. Man sollte daher einfach ein cvs update vorher ausführen. Danach sollte man unbedingt wieder die Lauffähigkeit des Programmes prüfen.
Anschließend kann man mit cvs commit seine Änderungen in das Repository einfließen lassen. cvs öffnet dabei einen Editor, in dem man ein paar kurze Bemerkungen über seine Änderungen eingeben sollte. Mit Hilfe von cvs log filename kann sich jeder diese Bemerkungen später ansehen. Damit man nicht mit vi, ed oder anderen Notbehelfen belästigt wird, sollte man vorher in der Umgebungsvariable EDITOR einen Editor eintragen, den man zu bedienen vermag.
cvs testet dann, ob ein commit möglich ist (oder ob man vorher ein update machen muß) und führt dann (hoffentlich) das commit auch aus.
- cvs add, cvs remove
Diese Befehle braucht man, um neue Files dem CVS unterzujubeln oder wieder wegzunehmen.
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