Nudge am 02.03.2012

SVN: subversion wird immer git-ter

in Linux, Open Source | Tags: Git, Subversion, SVN

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?

 

Nudge am 06.04.2011

Kaffeesatzlesen in Debian Testing

in Linux | Tags: Debian, Git, KDE, SVN

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).