Ein Grund mehr, Netzwerk-Verbindungen nicht im Desktop, sondern in /etc abzufackeln – warum sollte ein gewöhnlicher Nutzer einen Rechner in ein fremdes Netzwerk schleusen dürfen? Viel zu riskant, sagt da der Admin! Auf der anderen Seite nicht ganz so zeitgemäß. Der Trend geht eher zum Zweitrechner, und es gibt wohl mehr Rechner als Root-Accounts auf dieser Welt. Jeder ist also Root, und deshalb darf auch jeder seinen Rechner im Desktop dahin einstöpseln, wovon ihn sowieso nur noch ein beherztes sudo trennt.

Um das nervige Problem zu beenden, habe ich mir heute ein eigenes shutdown-Script geschrieben, welches myshutdown heißt und unter /usr/local/bin liegt. Es umountet also erst alle aktiven CIFS-Drives und beendet dann den Rechner per shutdown -h now. Zugegebenermaßen ein sehr krudes Mittel, weil KDE natürlich auch gern sauber beendet werden möchte, aber man kann es leider nicht allen recht machen.

#!/bin/bash

MNT=`mount | grep "type cifs" | cut -d' ' -f 3`
for mntpoint in $MNT
do
        umount $mntpoint
done

/sbin/shutdown -h now

Das ganze Script mit chmod a+x,u+s für alle ausführbar machen und wer will, kann das noch in die /etc/sudoers eintragen:

nudge   ALL=(ALL) NOPASSWD:/usr/local/bin/myshutdown

Das ganze kann man dann per khotkeys auf das KDE-Standard-Shutdown-Kürzel Strg + Alt + Bild runter mappen. Und schon gehts tierisch schnell ab in den Keller mit dem Rechner. Keine Timeouts beim Abwarten auf ein CIFS-Drive ohne Netzwerk mehr – hier sind 300 Sekunden Timeouts nicht Ungewöhnliches.

$ id3v2 -D MeinSong.mp3

Ganz intuitiv auch die weiteren Optionen zum Setzen von Daten: –artist (-a), –song (-t), –album (-A), –year (-y), –track (-T):

$ id3v2 --artist "Chuck Norris Girls" --song "Hell Yeah" MeinSong.mp3

Und das coolste Feature ist, dass der editierende Aufruf die Tags nicht löscht, sondern nur die spezifizierten Teile ersetzt. Hat man also eine ganze Platte ohne Tags, so kann man schnell mal

$ id3v2 --artist "Mölkau All Stars" --album "The red album" --year "1994" *.mp3

benutzen, um seine Sammlung zu korrigieren.

Viel Spaß!

class Test
{
    protected $active;
}

möchte eigentlich jeder die beiden Methode isActive() und setActive($active) implementieren – wohl zu 99% Wahrscheinlichkeit. Mit diesem Skript (Download unter http://www.vim.org/scripts/script.php?script_id=1707) geht das wie folgt. Man geht auf die Zeile

    protected $active

und gibt in dem vi-Kommando-Modus ein:

:InsertBothGetterSetter

und schon erscheint folgendes Gerüst

class Test
{
    protected $active;

    /**
    * get active
    */
    function getActive() {
        return $this->active;
   }

    /**
    * set active
    */
    function setActive($active) {
        $this->active = $active;
    }
}

Super-cool. Die Templates für die Funktionen lassen sich in der ~/.vimrc anpassen. Die Variablen %varname% und %funcname% kann man also auch beliebig einbauen, oder die eigene Tab-Weite anpassen. Damit sollte das Plugin soweit fit für den professionellen Einsatz sein und der Tipp- und Doku-Aufwand hat sich merklich verringert. Das ist richtig wohltuend.

getypte Variablen

Allerdings benutze ich gerne “getypte” Variablennamen, also $bActive oder $sURL. Dann würde die Funktion leider immer getSURL() oder getBActive() heißen – das ist natürlich nicht das Gelbe vom Ei. Für diesen Fall habe ich das Plugin ein klein wenig angepasst und ihr bekommt es hier http://www.lieber-linux.de/php_getset.vim zum Download. Es ist kompatibel zum Vorgänger-Script und erkennt camelCased-typisierte Property-Namen mit den Präfixen b (bool), n (int), s (string), f (float), dt (datetime), a (array) und r (ressource). Und das beste  daran ist: Jetzt stehen zwei weitere Template-Variablen bereit: %property% und %vartype%. Dadurch lässt sich das Ganze noch mit einem geschickten Casting versehen:

let b:phpgetset_getterTemplate =
\ "\n" .
\ "\t/**\n" .
\ "\t* Get %property%.\n" .
\ "\t*\n" .
\ "\t* @return %vartype%\n" .
\ "\t* @author Mathias Lieber\n" .
\ "\t*/\n" .
\ "\tpublic function %funcname%()\n" .
\ "\t{\n" .
\ "\t\treturn (%vartype%) $this->%varname%;\n" .
\ "\t}\n\n"

let b:phpgetset_setterTemplate =
\ "\n" .
\ "\t/**\n" .
\ "\t* Set %property%.\n" .
\ "\t*\n" .
\ "\t* @param %vartype% $%varname%\n" .
\ "\t* @return bool\n" .
\ "\t* @author Mathias Lieber\n" .
\ "\t*/\n" .
\ "\tpublic function %funcname%($%varname%)\n" .
\ "\t{\n" .
\ "\t\t$this->%varname% = (%vartype%) $%varname%;\n" .
\ "\t\treturn TRUE;\n" .
\ "\t}\n\n"

Am Ende würde das Klassen-Stub also folgendermaßen getypt aussehen:

class Test
{
    protected $bActive;

    /**
    * Get Active.
    *
    * @return bool
    * @author Mathias Lieber
    */
    public function getActive()
    {
        return (bool) $this->bActive;
    }

    /**
    * Set Active.
    *
    * @param bool $bActive
    * @return bool
    * @author Mathias Lieber
    */
    public function setActive($bActive)
    {
        $this->bActive = (bool) $bActive;
        return TRUE;
    }
}

Und das finde ich nun richtig gut. Wer mag, benennt noch getActive() in isActive() um.

Dazu ist natürlich eine ganze Reihe von Infrastruktur notwendig. Deswegen eignen sich solche Spielchen nur, wenn man einen eigenen Mailserver betreibt, an dessen Regelwerk man auch noch ungefragt herumschrauben darf. Da ich Herr meines eigenen Postfix bin, kann ich mich hier vollstens austoben. Das heißt, obwohl ich hier nur die Idee vorstellen möchte, kann es sein, dass ich einige Postfix-Spezifika berühre. Man möge es mir verzeihen.

Das Konzept

Zunächst war die Idee eine andere: Man möchte wissen, welche schlampigen Institutionen die eigenen Daten weiterverkaufen. Man gibt einem Shop oder einer Webseite daher nicht die eigentliche private Mail-Adresse, sondern einen Alias, der nur für diese Webseite bestimmt ist. Zumeist werden diese Aliase in einem LDAP oder in der Datei /etc/aliases angelegt. Zum Beispiel legt man sich im eigenen LDAP eine Reihe von kryptischen Email-Adressen zu, die etwa ixfklhs7@meine-domain.de heißen. Trifft nun nach einer gewissen Zeit Spam an diese exklusiv vergebene Email-Adresse ein, so kann man a) den Betreiber auffordern, die Weitergabe abzustellen (Abmahnung etc.), oder auch b) ganz einfach relaxen und diesen Alias streichen.

Vorteil dieser Lösung ist: Sie macht nur mäßig Aufwand und ist relativ leicht zu adminstrieren.

Nachteile sind: Die Alias-Email-Adresse gilt für immer. Habe ich viele Websites, auf denen ich gelegentlich shoppe, so muss ich irgendwann dringend aufräumen (OK, solange ich nicht viel Spam auf diese Aliase erhalte, kann ich sie aktiviert lassen).

Die Zeit-Komponente

Weiter darüber nachgedacht, könnte man sich das Leben noch einfacher gestalten und die Alias-Email-Adresse automatisch löschen lassen. Man vergibt quasi ein Ablaufdatum an eine Email-Adresse. Damit ist eine Email-Adresse eine Art temporäres Kommunikations-Token. Nehmen wir mal an, man definiert ein Token für 3 Monate als gültig. Wer innerhalb dieser 3 Monate auf meine Email antwortet oder selbst eine Email verfasst, der kommt durch. Danach wird die Email als nicht-existent abgewiesen (“Local recipient unknown” etc.)

Der Vorteil: Ich muss mich nicht mehr bemühen, alte Alias zu löschen.

Der Nachteil: Ich muss mich um ständig neue Aliase kümmern.

Die Praxis

Egal, ob es sich um den ersten oder um den zweiten Ansatz handelt: Sicherlich ist alles organisatorisch zu lösen, schöner wäre doch aber eine transparente Lösung. Diese würde uns die Nachteile jeder Lösung teilweise wettmachen. Ich stelle mir das so vor:

1. Meinem Mail-Client gebe ich ein Häkchen mit “individuelle Email erzeugen”. Er schaut also ins LDAP und vergibt eine neue EMail-Adresse, in dem er gleich ein neues, temporäres Benutzer-Objekt anlegt. Dort wird auch das Ablaufdatum hinterlegt. Als Maildrop-Attribut wird meine richtige Adresse hinterlegt. Ich könnte dann noch die Domäne des Shops hinterlegen, um a) zu wissen, wofür ich das angelegt habe, und b) um den Empfang später auf diese Domäne einzuschränken.

2. Es wird nun die temporäre Email-Adresse zur Erzeugung der Email verwendet.

2. Postfix versendet diese Email nichts-wissend.

3. Ein mir unbekannter Absender schreibt diese Email an. Nun kann ich die Virtual Lookups im LDAP so gestalten, dass ein Suchmuster verwendet wird, was nur nicht-abgelaufene Aliase heraussucht. Dazu muss ich das LDAP-Query des Postfix entsprechend mit zwei oder mehr Suchparametern ausstatten:

(&(mail=%s)(dtCreated>=20101012000000+0200))

Das Datum muss also dynamisch übergeben werden. Sollte das technisch schwierig werden, bietet es sich vielleicht an, per Cronjob täglich einmal abgelaufene Aliase aus dem LDAP zu streichen oder ein bAktiv-Flag auf FALSE zu setzen. Dann kann auch ein statisches Suchmuster in Postfix angegeben werden. Kombinierbar wäre das Vorgehen ebenso mit einem Filter, der die Absender-Domäne im LDAP-Objekt mit prüft. Das beugt der Absenderfälschung zwar wenig vor, aber es gibt eine Menge Domains und bis die passende gefunden ist, sollte der Spammer auf eine der bekannten RBL-Listen auftauchen.

4. Wenn die Email abgelaufen ist, so wird sie nicht gefunden und damit die Mail nicht zugestellt. Das Postfach bleibt leer.

Alternativ zu diesem Vorgehen könnte der MTA-Client ein Loopup im LDAP machen. Findet er dort einen Eintrag für die Ziel-Email im Adressbuch (also ein Bekannter), wird die Email nicht umgeschrieben. Ist kein Eintrag vorhanden, wird transparent eine temporäre Email-Adresse verwendet. Das setzt allerdings gute Pflege des Adressbuchs voraus.

Fazit

Soviel zu meiner Idee, ich werde mich demnächst damit etwas praktischer beschäftigen und würde eventuell noch ein paar Code-Zeilen dazu posten. Wenn jemand Anmerkungen oder weiterführende Ideen hat, bitte ich um aktiven Beitrag. Vielleicht kennt jemand schon Plugins, die so etwas tun?

varchar im Allgemeinen

Der Datentyp varchar ist ja dafür gedacht, eine variable Anzahl von Zeichen in der entsprechenden Spalte vorzuhalten. Das klingt erstmal sehr einleuchtend und flexibel. Der große Vorteil von varchar gegenüber seinem Komplement char ist also, dass bei einer Speicherung einer sehr kurzen Zeichenkette, wie “Hallo Welt”, nicht alle X vordefinierten “Plätze” gebucht werden, sondern nur soviel Speicher, wie benötigt wird. Das scheint also eine gute Sache zu sein, denn es erlaubt uns, mehr Daten zu speichern und dabei weniger Platz zu verbrauchen.

varchar in MySQL beleuchtet

Um herauszufinden, welche Länge für unsere MySQL-Applikation die Richtige ist, müssen wir natürlich wissen, wie MySQL im speziellen varchar-Spalten behandelt. Das kann sicherlich anders sein, als es Oracle’s größeres Hausprodukt oder der MSSQL-Server machen. Zunächst die historische Seite: 255 war lange Zeit die größte Anzahl, die man angeben konnte. Warum? Das kommt wohl von der verwendeten Programmiersprache, C. Dort wird eine Zeichenkette als Arrays von Bytes angelegt. Und das letzte Byte muss noch für das Abschluss-Zeichen “\0″ reichen – das Null-Byte. 255 Zeichen, plus Null-Byte, das macht genau 256 Zeichen. Wer sich ein bisschen mit Computern auskennt, erkennt hier gleich eine Zweierpotenz – also eine Zahl, die sich gut in die Speicherarchitektur einpasst. Sie ist in Informatiker-Worten “aligned“, also an günstigen Speichergrenzen “ausgerichtet“. Denn der Computer verarbeitet Daten ja immer in 8, 16, 32 oder 64 Bit – da machen sich Vielfache davon gut.

Noch deutlicher wird das MySQL-Verhalten, wenn man sich die alten Borland-Pascal-Strings anschaut. Dort hielt das erste Byte die Länge der Zeichenkette, und anschließend kam Zeichen für Zeichen ohne End-Terminierung. Und so legt auch MySQL die varchar-Daten an. Und historisch konnte MySQL ja auch nur US-ASCII-Bytes verstehen, keine komplexen chinesischen oder japanischen Zeichen, wie sie heute dank Unicode kein Problem mehr darstellen. Jedes Zeichen war also genau 1 Byte, also 8 Bit lang. Und dieses erste Byte hielt also die Länge der dann folgenden Zeichenkette. Es war also nicht möglich, keine größere Länge als 255 in einem Byte anzugeben. Daher also auch die 255.

Mehr als 255 Zeichen

Was ist denn mit mehr Text? Zum einen gibt es die Text-Spalte (bis 65,566 Zeichen), zum anderen lässt sich der MySQL-varchar-Typ aber auch mit mehr Zeichen betreiben. Das heißt, dass aber mehr Platz vorneweg nötig ist, um die folgende Textmenge zu beschreiben. Also mindestens 2 Byte. Gibt man also varchar(2010) an, so verbraucht das genau 2012 Bytes an Platz. Das ist für die Verarbeitung vielleicht ungut. Sollte man da auf eine ausgerichtete Größe wie 2046  (2048 – 2) wechseln? Man kann hier nur munkeln und vermuten, aber im Grunde wird es nicht schlecht sein, denke ich mir.

Varchar in der Praxis

Wenn MySQL bei Abfragen mehrere Tabellen über JOINs verknüpft, so kann es an dieser Stelle noch nicht wissen, wieviel Daten pro Zeile hineinflattern werden. Also reserviert es sicherheitshalber mal die maximal mögliche Zeichenanzahl an dieser Stelle. Mit varchar(255) werden also pro JOIN-Ergebnis-Zeile in dieser Spalte 256 Bytes verbraten. Auch wenn 99% der Einträge nur “Hallo” oder “Welt” enthalten – es ist ein Jammer. Aber besser, man weiß es wenigstens vor dem Layout der DB als hinterher. Schlimmer präsentiert sich allerdings noch der MySQL-Datentyp “TEXT” oder “BLOB” – der darf nämlich in JOINs auf keinen Fall im Speicher landen, sagt MySQL. Also wandert jede Temp-Table mit TEXT oder BLOB auf die Platte – das macht richtig Laune. Nun, es gibt hier aber auch einen Trick: Man legt /tmp auf Linux-Systemen einfach als tmpfs im RAM an. Das performt auch sehr gut mit PHP-Session-Files.

Was ist denn mit den Kanji oder chinesischen Zeichen?

Tja, jetzt wird es ja noch bunter. In ein Byte passt doch nur ein ASCII-Zeichen! Also muss jeder Zeichen-Platz nun erweitert werden, damit auch diese Schriftzeichen gespeichert werden können. MySQL macht das je nach dem angegebenen Zeichensatz, Collation genannt, unterschiedlich. Wer hier UTF-8 wählt, bringt MySQL dazu, pro Zeichen ganze 3 Byte (!) einzukalkulieren. Das bedeutet, ein varchar(255) verbrät in  vollem Zustand ganze 255 * 3 = 765 + 2 = 768 Bytes. Das ist dann schon eine ganze Menge. Knapp eine halbe Schreibmaschinenseite. Damit ein UTF-8-Text noch eine ein-bytige Längenbeschreibung erhält, darf er also ganze 85 Zeichen enthalten -> varchar(85) ist also dein Freund. Wer mit UCS-2 (16 Bit) gut fährt, vermeidet variable Zeichen-Byte-Längen und kann doch über 65,000 Schriftzeichen unterstützen. Das Unicode-Level von UCS-2 ist dasselbe wie mit den 3 Byte des UTF-8 in MySQL – für volle Unicode-Unterstützung wären hier nämlich bis zu 10 Byte pro Zeichen nötig. Allerdings wächst UTF-8 in den letzten Jahren, auch dank XML, Google und Co., zu einem De-facto-Standard heran.

Der Zeichensatz kann in MySQL zunächst auf Datenbank-Ebene angegeben werden. Wird dann bei Tabellen-Anlage nichts weiter mitgeteilt, wird der Datenbank-Zeichensatz übernommen. Wird der Tabelle etwas mitgegeben, verwendet diese spezielle Tabelle einen anderen Zeichensatz. Einer Spalte kann man ebenso einen besonderen Zeichensatz mitgeben. Ohne Angabe zieht wiederum der Tabellen-Zeichensatz. Das klingt auch erstmal sehr vernünftig, denn wo man nichts braucht, so man nichts verbrauchen. Allerdings muss man aufpassen, dass man Tabellen-Schlüssel vergleichbar hält. Möchte man also zwei Tabellen in einem JOIN verknüpfen und über (Un-)Gleichheit zweier Strings zusammenführen oder sortieren, dann sollten diese Spalten dieselbe Collation besitzen. MySQL beschwert sich sonst und verweigert die Operation. Toll, oder?

Was ist mit geraden Angaben wie varchar(32)?

Wer sich im Online-Bereich bewegt, weiß, wie oft Algorithmen 32Bit zurückgeben. Ist ja auch schön “aligned”. Allerdings, wie wir jetzt wissen, würde es dazu führen, dass MySQL immer 33 Bytes verbraucht – das ist richtig doof! Total “unaligned”. Was macht man denn damit? Erweitert man das auf varchar(63) – das wäre zwar richtig gut aligned, aber auch irgendwie viel zu viel Platzverschwendung in JOINs. Vielleicht geht man hier auf varchar(35) für 36 Byte (=32 + 4) oder varchar(47) für 48 Byte (= 32 + 16) – man weiß es nicht. Da würde ich gern mehr Erfahrung sammeln, welche Methode am Ende die Nase vorn hat. Der Vorsprung könnte sich allerdings im esotherischen Bereich bewegen, da hier Platten-IO, Netzwerk, Speicher, CPU und Luftfeuchte eine komplexe Wechselwirkung eingehen. Fakt ist, das selbst in UTF-8-Datenbanken sich hier eine ASCII- oder Latin1-Kodierung gut machen, um MD5-Werte oder PHP-Session-IDs zu speichern. Alles andere ist wirklich Perlen vor die Säue.

Fazit

Man vermeide varchar, wo es geht. Denn sie klingen erst mal praktisch, aber der Ärger ist hoch. Am besten, man führt numerische Strassenbezeichnungen ein, und Familien- oder Vornamen werden auf dem Bürgeramt auf BIGINT indiziert und Kommentare auf Websites werden nur noch per Doodle-Vorwahl akzeptiert: “How do you rate this site: Good, Better, Best”.

Im Ernst, man sollte sie wirklich vermeiden. Wo man sie braucht, sollte man die Länge auf sinnvolle Weise begrenzen, auf eine minimale Kodierung achten und die Vergleichbarkeit zwischen verknüpften Tabellen sicherstellen. Um wichtige Tabellen nicht mit varchar’s zu überfrachten, kann man diese auch gut und gerne in 2 Tabellen aufsplitten: Eine sehr schmale und schnelle für die Indizes mit minimalen Angaben und möglichst fixer Zeilenbreite und eine, die wenig frequentierte, erweiterte Textangaben beinhaltet. Zu guter Letzt beachte man noch die Ausrichtung, wo es möglich ist. In dieser Reihenfolge gehandelt, kann eigentlich nichts mehr schiefgehen. Viel Erfolg mit varchar in MySQL!

Zunächst ist es etwas schwerer, als es auf den ersten Blick erscheint. Auf der Rückseite ist es leicht gerundet, sodass es zwar gut in einer Hand liegt, aber beim Hinlegen wie eine Gemüsewiege hin- und herschaukelt, wenn man mal mit zwei Händen tippen will. Das ist wohl etwas unglücklich. Apple-typisch hat das iPad nur 4 echte Tasten: An, Laut/Leiser, Lock für automatische Drehung des Bildschirms und den vom iPhone bekannten Zurück-Button zentral unter dem Screen. Schauen wir mal weiter.

Wir haben hier die amerikanische iPad-Variante im Haus, denn die deutsche gibts ja noch nicht. Die Tastatur wirkt recht übersichtlich und die Tasten groß genug zum schnellen Tippen. Für jede Sondertaste muss allerdings umgeschalten werden, so auch beim @-Zeichen, und das in Web 2.0-Zeiten! Und die Tastatur bleibt dann in diesem Modus. Also muss man für eine Zahl zum Beispiel 3-mal tippen. Das könnte man besser machen.

Insgesamt ist die Haptik auf dem Touchscreen schnell erlernbar. Auch die winzigsten Elemente einer Website ließen sich meist problemlos treffen, das funktioniert wirklich sehr gut. Statt Tabs bietet der Safari-Browser hier nur Fenster an, die aber durch einen Schnellumschalter nebeneinander erscheinen und das Wechseln recht übersichtlich machen. Soweit konnten wir keine Probleme mit CSS oder JavaScript ausmachen – Web-Designer sollten also mit dem iPad keine zusätzlichen Probleme erwarten. Unsere auf 1024 Pixel optimierte Webseite passte auch absolut genau in den iPad-Screen. Jippieeh!

Dennoch ist nicht alles gold, was glänzt – das Display des iPad zum Beispiel glänzt nach 2 Minuten Benutzung stolz vor Fettabdrücken. Bei über 45 Grad Neigung sieht man als Nebensurfer nur noch das spiegelnde Glas des Displays, auf dem sich so nach und nach eine speckige Butterschicht bildet. Hier hätte man auch gleih mal ein fusselfreies Tuch beilegen können. Dieses gibt es sicherlich mit Steve-Jobs-Counterfei für günstige 19 Euro mit Apple-Shop Eurer Wahl. Aber im Ernst: Der Kampf zwischen Apple und Adobe nervt mehr, als er Früchte trägt – der fehlende Flash-Player wird so manche witzige Webseite den iPad-Nutzern verwehren.

Kommen wir zu weiteren Schwächen der Version 1.0: Die WLAN-Geschwindigkeit ist auch nicht das gelbe vom Ei, und der sehr aufgeräumt wirkende Desktop wirkt schnell leer und feature-arm. Es fehlen ebenso Bluetooth und Webcam – hier will Apple sicherlich ein iPad 2.0 (und später iPad 3.0) nachschieben und den Markt dreimal abschöpfen – das zu erkennen, macht nicht gerade glücklich mit dem Gerät.

Fazit

Insgesamt ist das Gerät für 750 Euro viel zu teuer für die gebotenen Features – es ist eher ein großes iPhone. Ich freue mich auf das WePad, denn ich schätze Freiheit, und da sieht es wohl mit dem Linux viel besser für eine persönlichere Einrichtung des Geräts aus. Und dort wird es wohl auch einen Flash-Player geben. Apple muss meiner Meinung nach aufpassen, nicht zum zweiten Microsoft zu werden – nämlich nicht zu versuchen, die eigenen Benutzer aus kurzsichtigen politischen Gründen so einzuschränken, bis sie es satt haben.

Ein einfacher Schnitt kann da zum Beispiel so aussehen:

$ mp3cut -o out.mp3 -t 1:24-2:12 beispiel.mp3

Und schwuppdiwupp hat man das angegebene Stückchen als neues MP3. Dabei benutzt mp3cut ganz intelligent Stellen, in denen es zu keinen Störungen kommt, um die Qualität an den Schnitträndern zu erhalten.

Hier verkünde ich: Wer dieses tolle Tool zum Sortieren von HTML-Tabellen NICHT einsetzt, gehört zurückversetzt nach Klasse Web 0.9! So, basta!

Ich möchte es nie mehr missen!

/* $Id$ */

Beim Einchecken macht SVN aus dem Keyword Id:

/* $Id: example.php 569 2010-02-19 15:17:49Z nudge $ */

Wenn nun jemand im Projekt ein bisschen herumsucht und nicht so richtig zurechtkommt, so sagt ihm diese Angabe, dass es sich um die Datei example.php handelt, die in Revision 569 des Projekts vorliegt, und diese wurde am 19.02.2010 um 15:17 das letzte Mal geändert, und zwar vom Benutzer Nudge. Das ist richtig toll, doch leider macht das SVN erst, wenn man alle Dateien mit diesem Keyword-Property ausgestattet hat. Besser also, man erleichtert sich das durch eine geeignete Voreinstellung. Diese bekommt man in der Datei ~/.subversion/config hin:

[miscellany]
enable-auto-props = yes

[auto-props]
*.php = svn:keywords=Id;svn:eol-style=native

Bisher erstellte Dateien berührt diese Voreinstellung nicht. Wenn man schon eine ganze Menge Dateien eingecheckt hat, so benutzt man am besten ausgecheckten (!) Pfad des Projekts folgenden Bash-Befehl, um alle darin enthaltenen PHP-Dateien nachträglich das Keyword-Property zu verpassen:

$ find ./ -name '*.php' -exec svn propset svn:keywords 'Id' {} \;

Und schon ist man dem PHP-Entwickler-Glück wieder ein Stückchen näher gekommen.

Dagegen sind die Domain-Nachahmer bei forrestle.org etwas lahmer und schaffen es wohl derzeit nicht, ihren lighttpd zu konfigurieren:

forrestle