SVN: subversion wird immer git-ter
in Linux, Open Source | Tags: Git, Subversion, SVNIch 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?
Danke DonTermi für die ausführliche Erklärung!
Wir benutzen bei Netresearch nur noch Git, die Vorteile sind einfach zu groß. Aber da scheint ja SVN jetzt aufholen zu wollen. Um git-svn habe ich bisher einen Bogen gemacht, wir hatten das einmal in einem Projekt benutzt, wo dann auch regelmäßig damit das Repo zerschossen wurde…
Bei Git entsteht der Konflikt beim Merge in der lokalen Arbeitskopie. Man sollte, bevor man seinen Branch mergt, den aktuellen master integrieren und die Konflikte lokal lösen, bevor der branch wiederum in den master gemergt wird.
So wie ich deine Ausführungen der svn merge-infos verstehe, braucht git diese Infos nicht. Denn die Merge-Historie ist durch mehrere verlinkte Parent-Commits immer da. Beim Mergen sucht git den letzten gemeinsamen Vorfahren, und der ist ja durch die Hashes immer eindeutig bestimmbar, während SVN ja numerisch zählt. Der ist sogar bestimmbar, wenn zwei Repos an zwei Orten “entstanden” sind, aber letztlich denselben Dateibaum enthalten…^_^
Die mergeinfo gibts in den SVN Eigenschaften und dient svn als Information, wenn ein Merge stattfindet, was bereits einmal gemerged wurde. Man kann somit bereits integrierte Sachen nicht noch einmal einbringen – es sei denn man benutzt beim merge den Parameter –ignore-ancestry. Dann greift svn bei einem merge nicht auf die mergeinfo und integriert den gesamten Bereich der gemacht werden soll – egal ob dieser schon einmal gemacht wurde. Kurzer Tipp:
# im root der Arbeitskopie
svn propget svn:mergeinfo .
Ansonsten unterscheidet sich subversion zwischen git grundlegend in der Zentralisierungssache. Bei subversion benötigt man immer einen svn server als zentralen Ansprechpartner – egal was man macht.
Git hingegen arbeit grundsätzlich dezentral. Um Grunde genommen kann man bei Git somit sagen das jede Arbeitskopie ein Fork ist und lokal vollständig lauffähig ist. Man kann somit mit seinem Laptop zu einem Kunden gehen und dort auf Softwarefehlersuche gehen. Patches und Änderungen können dann einfach lokal eingecheckt werden (Internetverbindung ist ja nicht nötig) und in der Firma können dann die Änderungen wieder auf die zentrale Arbeitskopie gepushed werden. Soweit ich weiss unterscheidet sich auch noch die Konfliktsache grundlegend von svn. Bei svn muss der Updater den Konflikt bei sich selbst beheben. Bei Git soll dies etwas anders sein in der Verantwortlichkeit.
Höre einfach mal hier rein (auch wenn´s schon etwas älter ist)
http://cre.fm/cre130
Bei Git gibt es auch eine abstrakte Ebene für subversion. Ist ein Git Plugin. Damit nutzt Du Git mit den normalen Subversion Commands. Es fühlt sich in dem Moment an wie Subversion aber im Hintergrund wird eben Git benutzt. Ich denke dies ist eine gute Methode für Git Umsteiger.