DE.STRUCTION: private

CVS an der UNI aufsetzen / benutzen

worum es geht

wenn man projekte oder aufgaben mit anderen an der UNI durchfuehrt, bietet sich ein eigenes CVS zur besseren verwaltung an.
"keine probleme mehr beim dokumentieren", "welches ist die neuste version", "wie du hast meine aenderungen nicht bekommen?" - das alles sollte der vergangenheit angehoeren. um ein CVS zu betreiben, gibt es zwei unterschiedliche moeglichkeiten. die client-server-variante pserver scheidet schonmal aus, da man wahrscheinlich stress mit der RBG bekommt. ausserdem sind entsprechende ports gesperrt. bleibt also nur die "lokale" variante ueber ssh zu tunneln.
dies ist unter manchen widrigen umstaenden aber nicht ohne weiteres moeglich. ich werde hier nicht auf das aufsetzen eines CVS eingehen, sondern mich vielmehr der loesung eines grundlegenden problems widmen.

wie es geht

der prinzipielle aufbau ist ganz einfach. einer der arbeitsgruppe stellt in seinem heimat-verzeichnis das CVS-repository zur verfuegung. nun kann jeder der sich erfolgreich ueber die UNI authentifiziert hat, mitmachen. dazu sollten die beiden umgebungsvariablen folgendermassen gesetzt sein:

dabei ist user dein UNIX-benutzername, rechner ein linux/UNIX-rechner im pool (es bietet sich z.B. amsel.informatik.hu-berlin.de an) und CVS-repository der vollstaendige Pfad zum CVS-repository.

ein kleines beispiel

die UNIX-benutzer "user1", "user2" und "user3" moechten zusammen im CVS arbeiten.
user1 stellt dabei das CVS-repository in seinem heimatverzeichnis zur verfuegung unter: /vol/fob-vol2/mi01/user1/cvs.
nun koennen sie ueber jeden linux/UNIX-pool rechner auf das CVS-repository zugreifen. im beispiel verwende ich "amsel" um dies von irgendwo (z.B. zu hause) mit "cvs" zu tun, stellen alle user dort (auch zuhause) ihre CVSROOT-umgebungsvariablen wie folgt ein:

wo ist das problem?

so lange alle user in der gleichen UNIX-gruppe (im beispiel "mi01") sind, gibt's kein problem. es muessen nur die notwendigen lese- und schreibrechte (fuer die gruppe) von user1 auf das CVS-repository gesetzt werden.
da es nun aber vorkommen kann, dass nicht alle mitglieder der arbeitsgruppe zufaellig in der gleichen UNIX-gruppe sind - weil sie nicht im gleichen jahrgang sind, nebenfaechler, oder so... - macht das probleme.

ein ansatz ist sicher, das gesamte CVS-repository fuer alle (wirklich alle am institut) les- und schreibbar zu machen.
das ist sicher nicht schoen, da dann jeder an die daten ran kann und ggf. lesen / veraendern kann.
"schoen ist anders" denkt man sich da vielleicht, aber das scheint mir vorlaeufig die einzige loesung zu sein, solange man sich nicht einfach eigene UNIX-gruppen dafuer ueber die RBG anlegen lassen kann.

einziger klaeglicher ausweg bleibt "security by obscurity":
man (user1) versteckt sein CVS-repository irgendwo im heimatverzeichnisbaum unterhalb eines les- und schreibgeschuetzten verzeichnisses (das X-flag muss aber gesetzt sein!).
dieses CVS-repository ist dann das "shared secret" der arbeitsgruppe.

das funktioniert aber nicht lange...

...denn spaetestens, wenn was neues eingecheckt wird, wird das entsprechende file in der CVS-verwaltung vom eincheckenden user uebernommen. ihm gehoert das file und auch seiner (unter umstaenden anderen) UNIX-gruppe. natuerlich sind auch die dateirechte verbogen. die fuer unseren einsatzzweck unpassende "umask" setzt natuerlich den schreibzugriff auf das file fuer alle zurueck, sodass nicht mehr alle zugriff haben.

immer wieder

wir muessen nach jedem durchgefuehrten "cvs commit" die rechte der neuen files korrigieren.
dies ist durch einen kleinen "kunstgriff" auch automatisierbar.

wie es wirklich geht

es gibt die moeglichkeit einen "pre-commit-check" beim einchecken durchfuehren zu lassen. diesen benutzen wir, um mit der identitaet es eincheckenden users die rechte rekursiv ueber das gesamte CVS-repository zu korrigieren. (das klappt natuerlich nur bei files, die auch dem user gehoeren)

eine kleine huerde gibt es allerdings noch:
da es sich dabei um einen "pre-commit-check" handelt, liegen die files, deren rechte korrigiert werden sollen noch gar nicht im CVS-repository. erst wenn dieser check erfolgreich verlaufen ist, werden die files angelegt.

daher bedienen wir uns zweier kleiner skripte:

  1. 'korrigiere': wartet 5 sekunden und korrigiert dann die rechte rekursiv unterhalb des CVS-repositories
  2. 'korr_start': startet das skript 'korrigiere' im hintergrund

beide skripte terminieren in jedem fall erfolgreich, damit der "pre-commit-check" ebenfalls erfolgreich ist und auch wirklich eingecheckt wird.
sie sind am besten von user1 direkt im CVS-repository abzulegen. jeder sollte sie lesen und ausfuehren, nicht aber schreiben koennen.

'korr_start' #!/bin/sh /vol/fob-vol2/mi01/user1/cvs/korrigiere 2>&1 >/dev/null & exit 0 'korrigiere' #!/bin/sh sleep 5 umask 000 chmod -fR a+rwX /vol/fob-vol2/mi01/user1/cvs/modul exit 0

dies gilt fuer den fall aus dem beispiel. modul ist dabei ein CVS-modul. fuer jedes modul sollte eine solche zeile existieren.

nun muessen wir nur noch dafuer sorgen, dass der "pre-commit-check" unser skript 'korr_start' ausfuehrt. dazu checkt user1 das modul CVSROOT aus, in dem verwaltungsinformationen ueber das repository gespeichert sind. in der arbeitskopie wird nun folgende zeile in das file 'CVSROOT/commitinfo' eingefuegt:

ALL $CVSROOT/korr_start

anschliessend die aenderungen wieder einchecken und los geht's...
...wer sich nicht mit dem praktischen 'cvs'-Befehl anfreunden kann, der sei auf Henryks Anleitung mit GUI verwiesen.


sollte dir ein anderer weg bekannt sein, die zusammenarbeit von benutzern unterschiedlicher UNIX-gruppen (sprich: jahrgaenge) mittels CVS zu ermoeglichen, bitte bescheid sagen!