fli4l - floppy-isdn4linux *Developer* cvs-regeln.txt ------------------------------------------------------------------------------- CVS-Regeln ---------- Vorweg: Ich benutze in diesem Text UNIX als Synonym für alle UNIX-Derivate, also auch Linux, FreeBSD, OpenBSD, etc. Alle Entwickler, die an FLI4L im CVS-Baum mitarbeiten, sollten folgende Regeln beachten: 1. Ein grudsätzliches Verständnis von CVS wird vorausgesetzt. Wer mit dem Kommandozeilenclient nicht klar kommt, darf auch Programme wie z.B. WinCVS, LinCVS, gCVS, etc. verwenden. Als sehr hilfreich hat sich das Buch "Open Source Development with CVS" erwiesen. Die deutsche Übersetzung findet sich unter: http://cvsbook.red-bean.com/translations/german/ Oliver Dawid hat freundlicherweise ein PDF-Dokument zur Verfügung gestellt: http://eisler.eisfair.net/~od/fli4l/cvsbuch.pdf 2. Die Datei files.txt: Jedes Mal, wenn eine Datei im CVS hinzugefügt oder gelöscht wird, ist diese Änderung in der Datei files.txt zu vermerken. Dies dient dazu, damit alle Dateien bei der Erstellung der Pakete ins richtige Zeilenumbruchsformat umgewandelt werden können. CVS wandelt nämlich munter zwischen DOS- und UNIX-Zeilenumbrüchen hin und her (In der Regel soll es so funktionieren, dass UNIX-Benutzer beim Checkout UNIX-Zeilenumbrüche bekommen und DOS- bzw. Windows-Benutzer beim Checkout DOS-Zeilenumbrüche, beim Commit entsprechend). In den Archiven, die nachher auf der Homepage landen, sollen aber die Zeilenumbrüche einheitlich sein. Dabei soll so viel wie möglich mit DOS-Zeilenumbrüchen abgespeichert werden, damit auch Windows- Texteditoren mit den Dateien umgehen können (kleinster gemeinsamer Nenner) Allerdings sollen einige bestimmte Dateien, z.B. die Scripts mkfloppy.sh und alle anderen Scripts, die direkt in einem UNIX-System ausgeführt werden sollen, im UNIX-Format vorliegen. Desweiteren ist es möglich, bestimmte Dateien direkt mit dem UNIX-Ausführbar-Flag zu versehen. Das hat für UNIX-Benutzer den Vorteil, dass sie die Dateien sofort ausführen können. Die Dateien der Dokumentation werden erst beim Erstellen der Distribution erzeugt und es ist auch nicht genau bekannt, wie die Dateien heißen und wie viele es sind. Deshalb werden diese Dateien speziell behandelt. Jede Zeile in der files.txt ist folgendermaßen aufgebaut: Der Status-Buchstabe ist einer der folgenden: u/U - Die Datei wird immer in eine Unix-Datei umgewandelt - Wichtig bei Scripts, die auf dem Client gestartet werden müssen, siehe oben d/D - Die Datei wird immer in eine DOS-Datei umgewandelt, das sollte bei fast allen Text-Dateien, wie u.a. der Doku der Fall sein. b/B - Binary - Die Datei wird ohne Änderungen übernommen. G - Die Datei/das Verzeichnis wird erst beim Übersetzen der Dokumentation generiert. Sie wird bei Vorhandensein in die Distribution übernommen. Sollte es sich um ein Verzeichnis handeln, werden alle darin befindlichen Dateien/Verzeichnisse übernommen Wird der Status-Buchstabe groß geschrieben, wird die Datei unter Unix außerdem ausführbar gemacht. Der Inhalt der Datei files.txt kann mit Hilfe des Scripts check-files.sh auf fehlende/überflüssige Einträge überprüft werden. Für alle, die kein UNIX-System zur Verfügung haben, gibt es 2 Möglichkeiten: 1. Check direkt auf dem Entwicklungs-Server: Nicht direkt im Verzeichnis /cvs bzw. /home/cvs arbeiten, das geht auf jeden Fall in die Hose! Es wird ein lokaler Check-Out in das eigene Home-Verzeichnis gemacht: eisler$ cd ~ eisler$ mkdir cvs eisler$ cd cvs eisler$ cvs -d /cvs checkout fli4l Danach kann check-files.sh in diesem Verzeichnis ausgeführt werden: eisler$ cd ~/cvs/fli4l eisler$ cvs -q update # Aktuelle Datein aus der Repository holen eisler$ ./check-files.sh 2. Mit den CygWin-Tools sollte es auch möglich sein, check-files.sh zu starten: http://cygwin.com/ 3. Log-Messages werden auf englisch geschrieben 4. Die Dokumentation wird als tex-Code erstellt, damit ist eine Nachverfolgung der Änderungen mittels cvs-diff möglich und eine changes-Datei der Doku muß nicht mehr gepflegt werden. 5. Änderungen an Paketen werden in der Datei PACKAGE/changes/PACKAGE.txt vermerkt. 6. Auf dem Laufenden bleiben mit Watches: Da bei einem "cvs update" meistens nur eine lange Liste vorbeiscrollt, in der man die "eigenen" Dateien so schnell nicht wiederfindet, bietet CVS die Möglichkeit, sich Änderungen in Dateien sofort per Mail mitteilen zu lassen. Um diese Benachrichtigung zu aktivieren, muss CVS zuerst wissen, wohin es die Benachrichtungsmails schicken soll. Die Benachrichtigungen gehen normalerweise an den Useraccount auf eisler und können dort mit mutt gelesen werden. Eine generelle Weiterleitung aller Mails, die auf eisler anfallen, kann mit einer Eintragung der eigenen Mailadresse in die Datei .forward im Home-Verzeichnis vorgenommen werden: $ ssh tobig@eisler tobig@eisler:~$ echo "fli4l@portfolio16.de" > .forward tobig@eisler:~$ cat .forward fli4l@portfolio16.de Damit ist die folgende Methode eigentlich obsolet, kann aber nützlich sein, wenn die CVS-Meldungen an eine andere Adresse gehen sollen als die anderen Mails auf eisler. Das eintragen der Mailadresse geht folgendermaßen: 1. Die CVS-Setup-Dateien müssen ausgecheckt werden: $ export CVSROOT=:ext:eisler.eisfair.net:/cvs $ export CVS_RSH=ssh $ cvs -q checkout CVSROOT 2. Als nächstes muss die eigene Mailadresse in die Datei CVSROOT/users eingetragen werden, dabei hat jede Zeile das Format : also z.B. tobig:cvs@portfolio16.de 3. Die Datei muss auf den neusten Stand gebracht werden, also: $ cvs -q commit -m "added myself to users" Jetzt werden alle Benachrichtigungen an diese Mail-Adresse geschickt. Watches werden mit dem Befehl "cvs watch add " (oder dem entspechenden Knopf in WinCVS, LinCVS, etc.) hinzugefügt, also z.B. wird mit cvs watch add intern/cvs-regeln.txt ein Watch auf diese CVS-Regeln gesetzt, also bekommt man immer eine Mail, wenn diese Datei geändert wird (gar keine schlechte Idee ;) ). Watches können mit "cvs watch remove " wieder entfernt werden. Um anderen mitzuteilen, dass man gerade an einer Datei arbeitet, kann man, bevor man seine Arbeit beginnt, den Befehl "cvs edit" benutzen. Dieser Befehl löst eine Mail an alle aus, die die Datei mit einem Watch beobachten und setzt die ausführende Person selber auf die Liste der "Watcher". Nach Abschluss der Arbeit (normalerweise nach dem Commit) muss der Befehl "cvs unedit" ausgeführt werden, um anzuzeigen, dass man mit der Arbeit an dieser Datei fertig ist. Weitere Informationen zu Watches gibt es im CVS-Buch Kapitel 6.3. 7. Auf dem Laufenden bleiben durch Lesen der Commit-Messages: Alternativ zu Watches bietet cvs auch die Möglichkeit, sich die commit-Messages per eMail zusenden zu lassen. Möchte man das für sich einrichten, checked man wie bei 6. beschrieben die CVSROOT-Dateien aus und editiert die Datei loginfo. Dort gibt es eine Zeile, die die Aktionen bei einem commit beschreibt: ^fli4l.* $CVSROOT/CVSROOT/log.pl %s -f $CVSROOT/CVSROOT/commitlog -m od@fet.uni-hannover.de -m jw5@konrad.inf.tu-dresden.de Im Augenblick wird hier die commit-Message in ein File geschrieben und als eMail an od und jw5 geschickt. Möchte man sich selbst hinzufügen, hängt man einfach seine eigene eMail-Adresse mit einem "-m" vorneweg an die Zeile dran und commited die Änderung. Von nun an trudeln alle commit-Messages per eMail bei einem ein. Teil der Commit-Message ist auch ein Link, über den man sich sehr komfortabel die Änderung über ein Webfrontend ansehen kann. Wird die Anzahl der an den Commit-Messages interessierten zu groß, kann man ja evtl. über das einrichten einer weiteren Mailing-Liste nachdenken. $Id$