bug fix

Hach, schön. Ich bin offensichtlich nicht der einzige auf der Welt, der nie weiß, was er als commit message schreiben soll. Gut, hin und wieder kann man auch benennen, was man eigentlich getan hat, aber meistens bessert man doch eh nur was aus oder fügt etwas hinzu. Bevor man also voll auf dem Schlauch steht, was man als commit message tippen soll, einfach mal den commit message generator unter whatthecommit.com anwerfen:

(\ /)
(O.o)
(> <) Bunny approves these changes. 

CVS - update

...heute steht eine weitere kleine Sitzung an unserem 'Hello World!!!'-Projekt an. Gleich stolpern wir über die erste Unaufmerksamkeit des vorigen Tages: CVS meldet ein 'No CVSROOT specified!' zurück, da wir gestern vergessen haben, unsere Umgebungsvariablen in die .profile oder die .bashrc unseres Homeverzeichnisses einzutragen. Da wir keine Lust haben, die Umgebungsvariablen bei jeder Sitzung neu zu setzen, holen wir dies schnell nach. Bevor wir uns nun an die Scripte setzen, gleichen wir unsere lokale Arbeitskopie mit dem Repository ab. Da wir ein wenig ungeduldig sind, lassen wir uns nicht erst mit
cvs -n -q update
die Dateien anzeigen, die aktualisiert werden müssen sondern führen mit
ich@client:~/Webseite$ cvs update
die Aktualisierung unserer lokalen Arbeiskopie direkt aus. CVS antwortet mit
cvs update: Updating .
P index.php
cvs update: Updating classes
P classes/HelloWorld.class.php
U classes/Html.class.php
und zeigt uns, daß unsere Scripte von gestern leicht abgeändert wurden (P = Patch) und, daß die Datei classes/Html.class.php in unserer Arbeitskopie komplett aktualisiert wurde (U = Update) - in diesem Fall ist die Datei unserem lokalen Verzeichnis hinzugefügt worden, da sie vorher nicht existierte. (Da hat also jemand an unseren Scripten weitergeschrieben.) Eine Beschreibung von update und dessen output findet man hier.
Ein cvs rlog Webseite zeigt uns dann noch an, welche Änderungen unsere Scripte erfahren haben und, was es mit der neuen Klasse Html auf sich hat. Nun können wir uns erstmal wieder unseren Scripten widmen und uns evtl. darüber aufregen, welchen Nonsense der andere Programmierer da fabriziert hat.

CVS - checkout und commit

...inzwischen langweilt uns das Script unsäglich und verlangt nach einer Änderung. Hinter dem 'Hello World' sollen mindestens ein paar Ausrufezeichen erscheinen. Wir löschen also die blöden Scripte auf dem Client oder schieben sie mit einem
ich@client:~$ mv Webseite Webseite.orig
aus dem Weg, da wir sie uns anschließend mit einem
ich@client:~$ cvs checkout Webseite
aus dem Repository holen wollen. CVS meldet
cvs checkout: Updating Webseite
U Webseite/index.php
cvs checkout: Updating Webseite/classes
U Webseite/classes/HelloWorld.class.php
und wir haben nun im Verzeichnis 'Webseite' die zu bearbeitenden Scripte. Am langweiligsten wäre es, in der Methode printOut das echo zu ändern. In meiner Überarbeitung der Scripte kommt mindestens eine Klassenvariable (und natürlich eine Methode, diese zu setzen) vor - aber das sei jedem selbst überlassen. Meine Änderungen betreffen sowohl die index.php als auch die HelloWorld.class.php und führen zu folgendem Ergebnis:
ich@client:~$ php index.php
> Hello World!!!
Da die Scripte wie gewünscht funktionieren, stellt man sie mit
cvs commit -m "mit Ausrufezeichen" Webseite
zurück ins Repository. Das commit umfasst hier das gesamte Modul, da ich ja beide Scripte geändet habe. CVS antwortet mit einem braven
cvs commit: Examining Webseite
cvs commit: Examining Webseite/classes
/home/ich/CVS/Webseite/index.php,v <-- Webseite/index.php
new revision: 1.2; previous revision: 1.1
/home/ich/CVS/Webseite/classes/HelloWorld.class.php,v <-- Webseite/classes/HelloWorld.class.php
new revision: 1.2; previous revision: 1.1
und hat die Revision von 1.1 auf 1.2 geändert. Ein
ich@client:~$ cvs rlog Webseite
zeigt diesmal an, welche Zeilen der Dateien geändert wurde, wer es war und wann.

CVS - ein erstes import

...wo war ich? Richtig, ich wollte ein tolles Script schreiben und das dann ins Repository übertragen. Lokal habe ich mir als ein Verzeichnis 'Webseite' angelegt, darin ein Verzeichnis 'classes'. In 'Webseite' habe ich folgendes Script index.php erstellt

<?php
include ('./classes/HelloWorld.class.php');
$helloworld = new HelloWorld;
$helloworld->printOut();
?>

und in 'classes' eine HelloWorld-Klasse (HelloWorld.class.php)

<?php
class HelloWorld {
 function HelloWorld() {
 }
 function printOut() {
   echo "Hello World\n";
 }
}
?>

Ein Aufruf von
ich@client:~/Webseite$ php index.php
liefert mir das gewünschte
> Hello World
Das Script funktioniert - hooray! Von der Hoffnung beseelt, daß dieses Script einmal etwas ganz großartiges wird, wenn es denn erst im Repository steht, führen wir das erste import aus
ich@client:~/Webseite$ cvs import -m "Wenn ich groß bin werde ich eine Webseite" Webseite PearlsForSwine-Software start
Dem import geben wir per -m einen Eintrag für's Log mit. Die letzten drei Parameter sind für den Namen des Moduls (hier: Webseite), für den Hersteller und für die Version (hier: start). CVS antwortet mit einem
I Webseite/CVS
I Webseite/classes/CVS
N Webseite/index.php
cvs import: Importing /home/ich/CVS/Webseite/classes
N Webseite/classes/HelloWorld.class.php
No conflicts created by this import
Na, das sieht doch gut aus. Wir haben nun im Repository ein Modulverzeichnis 'Webseite' angelegt und unsere Scripte übertragen. Jetzt schauen wir uns noch mit
ich@client:~/Webseite$ cvs rlog Webseite
das Log für unser Modul 'Webseite' an. Head 1.1, Revision 1.1, unser Kommentar ist auch drin - sieht gut aus.

CVS - erste schüchterne Annäherungsversuche

..."CVS? - Nutzt das noch wer?". Egal. Man soll ja alles mal ausprobiert haben. "Man lesen!" Richtig, sollte man. Aber heute ist Samstag und ein wenig 'Rumprobieren' macht ja auch manchmal Spaß. Das Folgende ist also ohne Gewähr zu genießen und ich bitte dann um konstruktive Kommentare wie "rtfm kaqnup!!elf!". Los geht's:
Wir haben einen Server und einen Client. Auf dem Client schreiben wir ein lustiges Testscript in PHP das dann in ein CVS-Repository auf dem Server - hier läuft ein Webserver etc. - übertragen werden soll.
Zuerst verbinden wir uns mit ssh auf den Server und erstellen dort in unserem Homeverzeichnis ein Verzeichnis CVS für das Repository
ich@server:~$ mkdir CVS
setzen die Umgebungsvariable CVSROOT auf dieses Verzeichnis
ich@server:~$ CVSROOT=/home/ich/CVS
ich@server:~$ export CVSROOT
wechseln in das Verzeichnis CVS
ich@server:~$ cd CVS
und erstellen dort das Repository
ich@server:~/CVS$ cvs init
Ein ls zeigt uns hier das neu angelegte Verzeichnis CVSROOT, das Repository ist also angelegt.
Vom Client aus möchten wir per Remote-Shell (per ssh) zugreifen, weshalb wir dort die Umgebungsvariable CVSROOT wie folgt setzen
ich@client:~$ CVSROOT=:ext:ich@server:/home/ich/CVS
ich@client:~$ export CVSROOT
Wir verbinden via ssh, setzen also noch die Umgebungsvariable CVS_RSH
ich@client:~$ CVS_RSH=ssh
ich@client:~$ CVS_RSH
Mit export bzw. echo können wir uns dann ansehen, ob wir uns auch nicht vertippt haben
ich@client:~$ echo $CVSROOT
> :ext:ich@server:/home/ich/CVS
Fein. Nun testen wir mal, ob wir per ssh an unseren CVS-Server kommen:
ich@client:~$ cvs version
> Client: Concurrent Versions System (CVS) 1.12.13 (client/server)
dann kommt der Prompt für das ssh-Passwort und dann
> Server: Concurrent Versions System (CVS) 1.12.9 (client/server)
Oha! Zwei unterschiedliche Versionen auf Client und Server. Jetzt brauchen wir nur noch ein paar ganz grandiose Dateien, die es auch wert sind, in das Repository geschrieben zu werden - *grübel*.