Ich habe letztens bei einer Diskussion mit Kollegen gehört, dass Subversion ab Version 1.7 (10/2011) nicht mehr diese häßlichen verstreuten .svn-Verzeichnisse benötigt. Das ist doch mal was! Was war das nur für ein Krampf… Die Info ist auch Anlass, um zu schauen, was sich sonst noch geändert hat.

Natürlich ist das neue zentrale .svn-Metadata-Verzeichnis bereits für sich eine große Sache. Aber auch die interne Struktur der Metadaten hat sich verändert: Komprimierte Ablage von Daten (hat git auch), Hashes auf Datei-Inhalte (hat git auch), damit auch die Verwendung von Referenzen bei gleichem Inhalt (hat git auch) und in der nächsten Version soll es wohl auch Stashes (temporäre Änderungs-Speicher) unterstützen – das hat git bereits.

Dann gibt es noch ein Feature namens Merge-Infos, die sich verbessert haben sollen. Hatte ich nie benutzt, ich weiß also nicht, was diese Merge-Infos bringen. Vom Namen her wüsste ich aber ungefährt, dass ich mir bei Git einen diff der beiden Vorgänger-Versionen zum Merge-Commit anschauen könnte, um eine “Info” über einen “Merge” zu bekommen. Und, das klingt auch toll: In-Memory-Caching auf SVN-Server-Seite. Das klingt tatsächlich schwer bei git umsetzbar, schließlich kann man das git-Protokoll oder http benutzen, muss aber nicht, und über ssh doch gehts auch. In der letzten Situation würde der In-Memory-Cache nicht ziehen, höchtens aufwändig zu invalidieren sein.

Noch ein Feature heißt “Optimierte Netzwerkübertragung”, vorrangig durch Komprimierung. Hier habe das Gefühl, das müsste git bereits so umsetzen, denn die Daten werden ja im Repo bereits komprimiert abgelegt, ganze ungeänderte Subtrees werden nur als Referenz von Revision zu Revision übernommen und wer mal auf einen aufwändigen Übertragungsprozess geschaut hat, sieht auch, wie vor der Übertragung ermittelt wird, welche Daten tatsächlich über den Äther müssen.

Also alles in allem habe ich den Eindruck, Subversion wird immer gitter. Ketzerische Frage meinerseits folglich: Warum traut sich das Subversion-Team nicht, SVN einfach wegzuwerfen und ihre Fähigkeiten im Git-Team einzubringen? Das wäre doch mal der berühmte Sprung über den Schatten. Oder braucht man tatsächlich zwei (inkompatible) Versionskontrollsysteme, von denen das eine die Fähigkeiten des anderen Stück für Stück nachprogrammiert?

Was sagt uns dies?

1
2
3
4

$ apt-get dist-upgrade
 
Vorbereitung zum Ersetzen von network-manager-kde 1:0.9~svn1175124-1
  (durch .../network-manager-kde_1%3a0.9+git20110318.941cde9-2_i386.deb) ...

$ apt-get dist-upgrade

Vorbereitung zum Ersetzen von network-manager-kde 1:0.9~svn1175124-1
  (durch .../network-manager-kde_1%3a0.9+git20110318.941cde9-2_i386.deb) ...

Da ist wohl gerade jemand von svn auf git umgestiegen…

(Ja und natürlich sagt es Euch, dass ich KDE benutze und seit einiger Zeit mal wieder den Network-Manager ausprobiere).

Wer seine Quelldateien in einem Subversion (SVN) vorhält, kennt die Keywords Id oder Revision, die man zum Beispiel in PHP folgendermaßen in einer Datei example.php als Kommentar benutzen kann:

1

/* $Id$ */

/* $Id$ */

Beim Einchecken macht SVN aus dem Keyword Id:

1

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

/* $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:

1
2
3
4
5

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

[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:

1

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

$ 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. 🙂