Maggistöpsel
„Leider konnte ich Sie telefonisch nicht erreichen.“
Dieser Satz scheint besonders bei Online-Marketingagenturen zur „Standard-E-Mail-Eröffnungsfloskel“ zu avancieren. Besonders beliebt ist der Satz im Zusammenhang mit Angeboten von selbstverständlich hoch lukrativen Werbekampagnen, zu denen der Absender der E-Mail festgestellt hat, dass sie hervorragend zu der gerade besuchten (also meiner) Webseite passen. Abgesehen davon, dass hinter diesen Kaltakquiseversuchen meist nicht mehr steckt, als das Bestreben des tausendsten (dynamischen|innovativen|internationalen|…) Online-Marketing-Startups das eigene Portfolio etwas aufzuhübschen, ist der Verweis auf den vorgetäuschten Versuch mich telefonisch zu erreichen, eher peinlich.
Im Zeitalter von Telefonmonopolisten und Wählscheibentelefonen mag es ja möglich gewesen sein die Behauptung aufrecht zu erhalten, man habe versucht anzurufen. Wenn ich aber weder einen Anruf in Abwesenheit, noch eine Nachricht auf der Mailbox feststellen kann, dann muss ich doch ernsthaft an der Seriosität des E-Mail-Absenders und seines Angebots zweifeln. Mir drängt sich da eher die Vermutung auf, das der Satz „Leider konnte ich Sie telefonisch nicht erreichen.“ dem Produkt einer – kostengünstigen, da von einem unbezahlten Praktikanten durchgeführten und unreflektierten – Mailingaktion, den Anstrich einer persönlichen Kontaktaufnahme geben soll.
Ebenso fragwürdig ist der Satz, wenn er im Kontext einer bestehenden Geschäftsbeziehung auftaucht. Vor allem wenn man aufgrund des sonstigen Inhaltes der E-Mail, davon ausgehen kann, dass sie an eine größere Zahl der Kunden oder Partner verschickt wurde. Will man mir hier durch die Blume mitteilen, dass man mich nicht anrufen konnte, weil man meine Telefonnummer verbummelt hat? Oder geht es darum, dass man für den Zweck zwar das richtige Kommunikationsmittel gewählt hat, allerdings zeigen möchte, dass man persönlich um meine Zufriedenheit als Partner oder Kunden bemüht ist. Für mich hinterlässt diese Floskel (sofern sie nicht begründet ist) eher den faden Beigeschmack, dass dem Absender meine Geschäftsbeziehung nicht einmal einen Anruf wert ist.
Liebe Leute, sofern der Satz nicht tatsächlich der Wahrheit entspricht, hat er einfach nichts – wirklich NICHTS – in einer E-Mail verloren.
MX Revolution unter Jaunty Jackalope
Nachdem es beim Upgrade von Hardy Heron zu Intrepid Ibex wesentliche Änderungen gab, was die Einrichtung von Komfortmäusen wie der MX Revolution angeht, darf – trotz der vermeintlichen Hiobsbotschaft, dass sich bei Ubuntu 9.04 alias Jaunty Jackalope wieder etwas geändert habe – erfreut festgestellt werden, dass alles beim alten geblieben ist. Bedeutet, dass der hier beschriebene Workaround weiterhin funktioniert und auch das Distributionsupgrade überlebt.
Auch wenn der beschriebene Weg recht gut funktioniert und mit ein wenig Übung wahrscheinlich sogar schneller erledigt ist, als den proprietären Treiber unter einem proprietären Betriebssystem zu installieren und dieses anschließen auch noch neu zu starten, ist es dennoch wünschenswert, dass die Unterstützung zeitgemäßer Mäuse ein Standardfeature moderner Linuxdistributionen wird. Diesem Anliegen sollte man zum Beispiel bei Ubuntu Brainstorm Nachdruck verleihen, indem man für die entsprechende Idee abstimmt.
Da es viel einfacher ist sich ein Feature zu wünschen, als es in die Realität umzusetzen, möchte ich an dieser Stelle allen Linux- und den ganzen anderen Open-Source-Entwicklern für ihre hervorragende Arbeit danken.
Browser-Update.org
Peter Kröner weist in der 40. Ausgabe seiner wöchentlichen Linksammlung unter Anderem auf die Initiative Browser-Update.org hin. Ziel der Initiative ist es, per dezentem Hinweis und sachlichen Argumenten, Benutzer zum Update auf einen aktuellen Browser zu bewegen. Das entspricht ziemlich genau meiner – vor einem Jahr geäußerten – Vorstellung von einer Browser Upgrade Initiative. Gerade gestern hatte ich mit einer webseiten-spezifischen Implementierung dieser Idee begonnen. Die Gestaltung einer Infoseite zu den Nachteilen alter und den Vorteilen neuer Browser kann ich mir dank Browser-Update.org nun sparen.
IE 6: Während die Deutschen diskutieren …
…lassen die norwegischen Webmaster grüne Boxen sprechen und an anderer Stelle wird zum IE Death March geblasen.
Vor fast genau einem Jahr schwappte mal wieder der Frust über den Internet Explorer 6 durch einige deutsche Blogs und entlud sich in einer kleinen Revolte. Auch wenn sich die meisten Webmaster darüber einig sind, dass man den IE 6 endlich los werden muss, wurde damals viel diskutiert. „Sollte man den Nutzer wirklich bevormunden?“, „Ist es nicht Aufgabe eines guten Webmasters, seine Seite möglichst kompatibel zu halten?“. Damals wie heute halte ich eine gezielte Aufklärungskampagne für eine sinnvolle Maßnahme.
Da es die aktuellen Aktionen gegen den IE 6 in den Heise-Newsticker geschafft haben, ist es vielleicht an der Zeit, auf den Zug auf zuspringen. Vielleicht schafft es das Thema ja aus der Webworker-Ecke heraus in eine allgemeinere Wahrnehmung? (Sicherheit und Datenschutz sind Stichworte, die in diesem Zusammenhang die Aufmerksamkeit erhöhen könnten.) Andererseits sollte man das vielleicht lieber nochmal ausführlich diskutieren…
Minimal-Profiling für PHP mit Xdebug und Webgrind
Die effiziente Nutzung begrenzter Ressourcen, ist nicht nur ein ökonomisches und ökologisches Anliegen, auch bei der Entwicklung von Webanwendungen ist der schonende Umgang mit der zur Verfügung stehenden Rechen- und Speicherkapazität ein wichtiger Aspekt.
Bei einem kleinen Backend-Skript mag es wenig sinnvoll sein auch noch die letzte Mikrosekunde rauszukitzeln. Bei offenen Webpräsenzen, deren Server der potentiellen „Gefahr“ ausgesetzt ist, durch einen Link von einer großen Webseite aufgrund des Besucheransturms in die Knie gezwungen zu werden, sollten allzu enge Flaschenhälse jedoch vermieden werden.
Zum Aufspüren von Geschwindigkeitsproblemen in PHP-Anwendungen, die durch einzelne Funktionen verursacht werden, bietet sich die Kombination aus Xdebug und Webgrind an, um ein minimales Profiling durchzuführen.
Xdebug installieren und einrichten
Xdebug wird als PHP-Modul installiert und bietet neben dem Profiling auch nützliche Möglichkeiten zum Debugging von PHP-Skripten. Für Ubuntu gibt es ein Paket in den Repositories, weshalb die Installation auch schnell erledigt ist (ein installierter Apache mit PHP vorausgesetzt):
sudo apt-get install php5-xdebug
Anschließend muss man in der Datei /etc/php5/conf.d/xdebug.ini das Profiling aktivieren. Dabei empfiehlt es sich die Trigger-basierte Variante zu wählen, da ansonsten bei jeder Ausführung eines PHP-Skripte eine Profiler-Datei geschrieben wird, was bei umfangreichen Anwendungen schon mal einige Megabyte sein können.
; Laufendes Profiling deaktivieren
xdebug.profiler_enable = 0
; URL-Trigger ?XDEBUG_PROFILE aktivieren
xdebug.profiler_enable_trigger = 1
Standardmäßig werden die Profiler-Dateien in das Verzeichnis /tmp geschrieben. Dies lässt sich jedoch über die Option xdebug.profiler_output_dir nach belieben anpassen. Ruft man nun eines seiner PHP-Skripte mit dem zusätzlichen Parameter XDEBUG_PROFILE (z.B. http://localhost/MeinSkript.php?XDEBUG_PROFILE) auf, so landet eine Datei mit dem Namen cachegrind.out.???? im eingestellten Verzeichnis. Der Inhalt dieser Datei ist auf den ersten Blick nicht wirklich aufschlussreich, allerdings lässt sich das ändern.
Auswertung mit Webgrind
Als Mittel der Wahl zur Auswertung der Cachegrind-Dateien werden in der Xdebug-Dokumentation KCacheGrind und WinCacheGrind empfohlen. Möchte man aber weder KDE-Komponenten, noch das Betriebssystem aus Redmond auf seinem Rechner installieren, muss man sich nach einer Alternative umsehen. Als betriebssystemunabhängige und unkomplizierte Möglichkeit bietet sich Webgrind an.
Die Installation ist denkbar einfach und in drei Schritten erledigt (vorausgesetzt man hat einen lauffähigen Webserver, wovon auszugehen ist, wenn man PHP-Skripte testen will): 1. Herunterladen 2. An geeigneter Stelle entpacken 3. Im Browser aufrufen.
Wer für Xdebug ein anderes Verzeichnis für die Profiler-Dateien gesetzt hat, der muss allerdings noch den Pfad in der config.php entsprechend anpassen.
Sofern entsprechende Profiler-Dateien vorhanden sind, lassen sich diese unter Webgrind über die Dropdown-Box am oberen Bildrand auswählen und per Klick auf den Button auswerten. Die Auswertung lässt sich wahlweise prozentual, nach Milli- oder Mikrosekunden vornehmen. Die Übersicht bietet die Möglichkeit sich anzeigen zu lassen durch welche Funktion die jeweils betrachtete Funktion aufgerufen wurde und die dazugehörige Stelle lässt sich auch im Quelltext anzeigen.
Fazit
Mit Xdebug und Webgrind lässt sich relativ einfach ein kurzer Überblick, über die Laufzeiten der einzelnen Funktionen eines PHP-Skripts, erreichen. Flaschenhälse lassen sich so schnell identifizieren und potentiellen Problemen bei steigenden Besucherzahlen, kann somit vorgebeugt werden.
Blog günstig abzugeben
Ein kurzer Streifzug durch einige Blogs mit Kommentaren zum Verkauf von „Basic Thinking“ zeigt, dass es durchaus unterschiedliche Meinungen zur Höhe des erzielten Preises (46.902 Euro) gibt. Während die einen es als ordentliche Summe auffassen (was es aus dem Kontext losgelöst ja auch ist), zeigen sich andere eher enttäuscht. Ich bin in Anbetracht des Bekanntheitsgrades von „Basic Thinking“ und dessen Präsenz in Suchmaschinen und allgemein im Web, schon etwas verwundert und zähle mich eher zu letzteren. Ob knapp 46.000 Euro (das bekannte Internetauktionshaus möchte ja auch seinen Teil vom Kuchen bekommen) ein angemessener Betrag für – in drei Jahren fleißig zusammengebloggtes – mehr oder weniger sinnvolles Text-, Bild-, Ton- und Video-Material ist, muss jeder für sich beurteilen. Die durch das ZDF festgehaltene Freude von Robert Basic, scheint mir jedoch etwas verhalten.
Das Problem mit dem Wert eines Blogs liegt wohl zum Teil darin begründet, dass sich der Erfolg eines Blogs anhand der Größe der Stammleserschaft und der damit indirekt zusammenhängenden Verlinkung durch andere Blogs bemisst. Stammleser werden aber blind für Werbeanzeigen und über die Kommentarfunktion lassen sich auch keine umfangreichen Kontaktdaten sammeln (zumindest würde wohl der Versuch verwertbare Daten zu sammeln, die Anzahl der Kommentare erfolgreich auf einen Wert nahe Null reduzieren). Andere Blogger, welche sich auf den Inhalt eines Artikels beziehen, sind noch stärker auf den Inhalt fokussiert und dürften noch weniger auf Werbung klicken. Hinzukommt außerdem noch, dass viele Abonnenten von Fullfeeds die Webseite gar nicht erst besuchen.
Ein weiterer Aspekt der die Einzigartigkeit und damit den Erfolg eines Blogs ausmacht, ist die persönliche Note. Blogs behandeln Themen die eine konkrete Person interessieren und in den Artikeln sind in der Regel Meinungen und Wertungen zu finden oder der Inhalt bezieht sich grundsätzlich auf ein persönliches Thema. Themenblogs die sich möglichst objektiv und umfangreich mit einem Themenbereich auseinandersetzen, gleichen meiner Meinung nach eher Newsseiten oder Magazinen, die sich lediglich der Technik von Blogs bedienen. Bei „echten“ Blogs spielt hingegen entweder die Persönlichkeit des Bloggers, der individuelle Schreibstil oder die persönliche Themenauswahl eine wichtige Rolle und machen damit den Wert aus.
Auf den Fall „Basic Thinking“ bezogen bedeutet es eben, dass die Domain und das Blog ohne Robert Basic wesentlich weniger wert sind. Ich würde vermuten, dass Blogs wie Macnotes oder Netbooknews (ehemals Eee PC News) für einen weit höheren Betrag den Besitzer wechseln würden, da hier die möglichst objektive Berichterstattung im Vordergrund steht und sie somit losgelöst von einer bestimmten Person(engruppe) funktionieren. Allerdings ist die Frage, ob diese Seiten wirklich als Blog im engeren Sinne einzustufen sind. Letztendlich sind 46.000 Euro dann vielleicht doch ein ordentlicher Betrag für das meistverlinkte Blog Deutschlands.
MX Revolution unter Intrepid Ibex
Die folgenden – für Nicht-Mauspuristen – unschönen Worte findet man seit dem 14. September auf der ehemaligen Entwicklerseite von btnx.
… Ubuntu Intrepid Ibex, which is to be released in October, breaks the foundations that btnx was built on. It seems that the kernel input event pipes can no longer be read. It is most likely related X.Org v.7.4. This means I will stop all development of btnx. …
War die Button-Extension von Olli Salonen damals noch der anwenderfreundliche Mausdompteur, zwingt einen nun das Release der neusten Ubuntu-Version 8.10 alias Intrepid Ibex zur Suche nach alternativen Möglichkeiten. Abgesehen davon, dass diese Alternativen bei weitem nicht so komfortabel sind wie btnx, haben sie auch den ein oder anderen Nachteil. Um die Funktionalität meiner MX Revolution, die ich mit btnx erreicht habe, auch unter Intrepid Ibex herzustellen, habe ich einige der Möglichkeiten kombiniert und nachfolgend zusammengefasst (damit ich später nicht danach suchen muss):
Desktopwürfel mit der Daumenwippe drehen
Erfreulicherweise erkennt Ubuntu 8.10 die Daumenwippe der MX Revolution. Wie sich mit Hilfe von xev herausfinden lässt, wird das Bewegen der Wippe nach Vorne als Button13 und nach Hinten als Button15 erkannt. Über den CompizConfig-Einstellungs-Manager (compizconfig-settings-manager aus den universe-Paketquellen) können dann beim „Rotate Cube“-Plugin die Buttons für die beiden Drehrichtungen festgelegt werden. Da hier nur bis Button9 ausgewählt werden kann, muss die Eingabe über die Edit-Schaltfläche vorgenommen werden.
Laufverhalten des Scrollrads
Zu meinem Erstaunen ist die Funktionalität des Scrollrades standardmäßig so wie ich es haben möchte. Das Scrollrad schaltet ab einer gewissen Geschwindigkeit automatisch in den Freilauf. Wenn es sein muss, lässt sich allerdings über das, auch in btnx integrierte, Tool revoco, das Verhalten des Scrollrads noch weitreichender steuern. So kann, neben unterschiedlichen Geschwindigkeiten abhängig von der Drehrichtung oder der Festlegung einer anderen Maustaste für den Wechsel zwischen freiem und „gerastertem“ Lauf, seit Version 0.5 auch der Batteriestatus abgefragt werden.
Suchtaste als mittlere Maustaste
Da sich die Suchtaste leichter drücken lässt als das Mausrad, ist es bei MX Revolution-Besitzern beliebt, die Suchtaste als mittlere Maustaste zu nutzen. So auch bei mir. Um dies zu erreichen, muss in einem ersten Schritt die Tastenbelegung für Suchen gelöscht werden, da sich sonst die Tracker Suche öffnet, wenn die Suchtaste betätigt wird. Dies lässt sich leicht über System » Einstellungen » Tastenkombinationen bewerkstelligen.
Anschließend werden die Programme xbindkeys aus dem gleichnamigen Paket und xte aus dem Paket xautomation benötigt. Mit dem üblichen „sudo apt-get install xbindkeys xautomation“ ist das auch schnell erledigt. Nun muss noch eine entsprechende Konfigurationsdatei namens .xbindkeysrc im Heimatverzeichnis des Benutzers angelegt und mit dem richtigen Inhalt gefüllt werden. Sofern keine anderen Einstellungen vorgenommen werden sollen, enthält die Datei die folgenden zwei Zeilen:
"xte 'mouseclick 2'"
c:0xE1
Die erste Zeile gibt an, welches Programm ausgeführt werden soll (in unserem Fall soll das Programm xte einen mittleren Mausklick simulieren) und in der zweiten Zeile wird die auslösende Taste angegeben (Der obige Hexcode steht dabei für die Suchtaste). Mit „xbindkeys -n -v“, lässt sich die Konfiguration testen. Der Parameter „n“ teilt xbindkeys dabei mit, dass es nicht im Hintergrund gestartet werden soll und mit „v“ wird auf den gesprächigen Verbose-Modus umgeschaltet. Läuft mit der vorgenommenen Einstellung alles zufriedenstellend, sollte man für xbindkeys noch einen Autostarteintrag anlegen (diesmal ohne Parameter), was leicht über System » Einstellungen » Sitzungen zu realisieren ist.
Fazit
Es ist zwar etwas Handarbeit notwendig, aber Ubuntu 8.10 bringt bereits viele Voraussetzungen mit, die für die Konfiguration der MX Revolution notwendig sind. Die Daumentasten für „Vor“ und „Zurück“ im Browser funktionieren übrigens out-of-the-box. Der Workaround für die Suchtaste lässt sich auch verschmerzen, wenn man davon ausgeht, dass man die Einrichtung nicht täglich vornehmen muss. Dennoch sollte dies nicht davon abhalten, bei Ubuntu Brainstorm für eine vernünftige Unterstützung zeitgemäßer Komfortmäuse abzustimmen.
Das große CMS-Dilemma
Die beiden Artikel von Gerrit und Peter sowie die jeweils daran anschließenden Diskussionen veranschaulichen wieder einmal das Dilemma im Zusammenhang mit der Auswahl und Nutzung von Content Management Systemen. Insbesondere bei kleineren Websites, die durch Benutzer (also nicht Entwickler oder Designer) mit Inhalten versehen werden sollen, driften die identifizierten Anforderungen und die durch die verfügbaren CMS realisierten Möglichkeiten oft stark auseinander. Erschwerend kommt hinzu, dass die schiere Menge der verfügbaren CMS jeden Normalsterblichen vor eine unlösbare Evaluationsaufgabe stellt.
Diskrepanz zwischen Anforderungen und Features
Generell soll das gesuchte CMS einfach zu bedienen sein, gleichzeitig aber genügend Freiheiten bieten um die geplante Struktur sowie Design und Layout der Website umsetzen zu können. Die verfügbaren CMS sind aber einerseits schwergewichtige und komplexe Gebilde mit vielfältigen, meist nicht benötigten Features, die auch gestandene Webentwickler abschrecken. Auf der anderen Seite existieren vielversprechende Ansätze mit übersichtlichen und einfach zu bedienenden Backends. Diese in der Regel schlanken Vertreter der Spezies CMS befinden sich allerdings meist in einem frühen Stadium der Entwicklung und weisen damit nicht alle benötigten Features auf oder sind noch nicht für den produktiven Einsatz geeignet. Hinzukommt dass sich bei jungen Projekten schlecht abschätzen lässt, wie aktiv diese in Zukunft gepflegt werden, was für einen langfristigen Einsatz ein K.O.-Kriterium darstellen sollte. Es stellt sich die Frage warum der Bereich der schlanken, leicht zu bedienenden und darüber hinaus ausgereiften CMS so dünn besetzt ist.
Vom schlanken Projekt zur überladenen Bloatware
Die Ursache für dieses Dilemma liegt meiner Meinung nach an dem Verlauf der Entwicklung eines CMS-Projektes. Initialzündung vieler in den letzten Jahren entstandener CMS-Projekte ist die Erkenntnis, dass die verfügbaren CMS viel zu überladen und die Backends zu umständlich sind. Die ersten und wichtigsten Features sind dann dank der Verfügbarkeit ausgereifter Frameworks schnell implementiert. Danach entscheidet sich dann ob das Projekt wieder einschläft oder aufgrund des Anklangs bei anderen Usern aktiv weiter entwickelt wird. Und genau hier liegt auch die Ursache des Dilemmas: Damit das Projekt erfolgreich bleibt, müssen die Entwickler auf die Wünsche der User eingehen, also Features die von einer Vielzahl der Nutzer gewünscht werden hinzufügen. Außerdem besteht bei einer aktiven Nutzerschaft ein Anreiz weiterzuentwickeln und möglichst regelmäßig neue Versionen herauszubringen, da dies verstärkt mit hoffentlich positivem Feedback belohnt wird. Letztendlich führt dieser Entwicklungs- und Implementierungsdrang aber dazu, dass das CMS immer komplexer wird. Diejenigen User, die die Entwicklung des CMS schon seit einem frühen Stadium mitgemacht haben, werden von der Komplexität nicht abgeschreckt, da sie sich mit dem System auskennen. Für die meisten anderen erscheint es jedoch im schlimmsten Fall wie überladene Bloatware. Dieser Trend zur „Featuritis“ bei zunehmendem Projektalter, lässt sich gerade bei populären CMS oder Blogsystemen – wie etwa WordPress – sehr gut beobachten.
Konsequente Beschränkung auf Kernfunktionalität
Diesem Problem ist sicherlich nur mit einer sehr disziplinierten Konzentration auf zuvor festgelegte Kernfeatures und einer konsequenten Modularisierung beizukommen. Wobei sich hier über die Kernfeatures sicherlich vortrefflich streiten lässt und zudem eine einfache Bedienbarkeit nicht automatisch aus der Beschränkung auf das Wesentliche resultiert. Darüber hinaus dürfte das eine oder andere CMS-Projekt mit genau diesen Vorsätzen an den Start gegangen sein. Die Tatsache, dass es das allseits beliebte leicht zu bedienende CMS (noch) nicht gibt, legt die Vermutung nahe, dass sich dem dargestellten Dilemma nicht entkommen lässt.
Wer möchte den Gegenbeweis antreten und der Welt das gefühlte milliardste CMS bescheren?
Inkscape-Vektorgrafiken versionieren
Arbeitet man an etwas umfangreicheren Vektorgrafiken – etwa weil sich diese sehr gut als PDF in LaTeX-Dokumente integrieren lassen – kann es manchmal ganz sinnvoll sein, diese mit Versionsnummern zu versehen. Wenn man dies nicht von Hand machen möchte, bietet sich dazu eine entsprechende Versionsverwaltung an. Nachfolgend möchte ich kurz beschreiben, wie man Inkscape-Vektorgrafiken mit Subversion (SVN) verwalten kann (Wobei ich auf Details zum Umgang mit Subversion oder Inkscape verzichten werde.). Dabei machen wir uns zunutze, dass SVG-Grafiken XML-Dokumente sind und Texte in der Grafik in der Datei im Klartext auftaucht (Anmerkung: Mit komprimierten SVG-Grafiken geht es nicht.).
Grafik vorbereiten
Als erstes müssen wir für Subversion ein Keyword in die Grafik einfügen, welches anschließend bei jedem Commit durch die aktuelle Revision ersetzt wird. Hier bietet sich $Rev$ an. Selbstverständlich kann hier auch $Id$ oder eines der anderen von Subversion unterstützen Keywords genutzt werden.
svn:keywords Property setzen
Anschließend muss Subversion noch mitgeteilt werden, dass es bei jedem Commit das Keyword $Rev$ mit der aktuellen Revision ersetzen soll (selbstverständlich muss zuvor ein Repository angelegt, die Grafik importiert und ausgecheckt worden sein). Mit dem folgenden Befehl auf der Kommandozeile teilt man Subversion mit, dass $Rev$ als Keyword behandelt werden soll:
$ svn propset svn:keywords "Rev" Beispiel.svg
Grafikbearbeitung fortsetzen und Änderungen einchecken
Jetzt kann man wie gewohnt an der Grafik weiterarbeiten, mit dem Unterschied, dass man nach getaner Arbeit sein Werk im Repository aktualisieren sollte, damit das ganze mit der Versionierung auch seinen Sinn hat:
$svn commit -m "Orangefarbenes Ding eingebaut"
Da Subversion das Keyword brav ersetzt, hat man immer die aktuelle Revisionsnummer in der Grafik stehen. Abgesehen davon kann man natürlich jederzeit auf ältere Versionen zurückgreifen und entsprechende Tags oder Branches erstellen. Man kann eben all die Vorteile der Versionsverwaltung mit Subversion nutzen. Leider bemerkt Inkscape (anders als etwa gedit) eine zwischenzeitliche Änderung der gespeicherten Datei nicht, weshalb man darauf achten sollte Inkscape vor dem Commit zu schließen, da man sonst mit der falschen Versionsnummer in der Grafik weiterarbeitet.
Übrigens: Möchte man, dass die Versionsinformation mit auf ausgedruckten oder exportierten Grafiken landet, dann sollte man bei Inkscape den entsprechenden Keyword-Text auf und nicht, wie im Screenshot zu sehen, neben der Seite platzieren.