(zu Hotaka)
Well, am WE hab ich mich mit Felix gerade über Versionskontrollsysteme und unsere Experimente mit HG unterhalten, als mich jemand 'von der Seite angemacht' hat, dass doch wohl im Moment alle Welt weg von HG und hin zu GIT wechseln würde.
Well, das konnte ich so nicht glauben, aber ich wollte mir die verschiedenen Tools dann doch mal anschauen - vor allem in Hinsicht auf SVN Kompatibilität - denn ich setze SVN sowohl für meine Arbeit, also auch für mich [browser:/ Privat] ein.
Na, denn ma auf zu dem Vergleich:
GIT
... hab ich mir als erstes dran genommen, und bin erst mal dran gescheitert, das das perl-script, dass den SVN-Modus macht via Fink natürlich nicht mit meiner Installation zusammenwollte, weil diese alten Perlhacker natürlich alle davon ausgehen, das Perl in /usr/bin/perl liegt. Well, tut es bei mir nicht, bzw, in /usr/bin liegt eine alte version von Perl, die eine bestimmte Library nicht enthält, die aber das Skript benötigt. ARGH! Also erst mal einen Patch zusammengebaut und an den Maintainer geschickt der das auf /usr/bin/env perl ändert. Oh well.
Danach war aber eigentlich alles dandy, bis auf die Tatsache, das ich trotz längerem nachlesen ums verrecken nicht verstanden habe, welchen Sinn diese komische Staging-Area "Index" haben soll, die man bei GIT immer zuerst mal auffüllen muss, bevor man sie Comitten kann.
Well, GIT is powerfull - aber für meinen Geschmack zu sehr an den Geschmack von Herrn Torvalds angepasst. Mag ja sein das er nur mit inkonsistenten und komplizierten Kommandozeilenoptionen effizient arbeiten kann. Ich jedenfalls hab was besseres verdient. Ausserdem erzeugt es bei mir Ablehnung wenn Herr Torvalds aus seiner Göttlichen Eingebung sämtliches anderes für Mist erklärt und dann etwas neues macht was deutlich komplizierter ist als die anderen - ohne das klar wird, wieso diese Komplexität der richtige Default ist und man nicht das Einfache zum Default machen kann, um das komplizierte als Option anzubieten.
Fazit: Funktioniert, push und pull zum SVN server waren kein Problem und das ist schon mal ein starkes Stück. Beindruckendes Tool, dass aber auch viel Ablehnung in mir erzeugt.
... war dann der zweite Kandidat, der nicht mehr viel Langsamer daherkommt als die anderen beiden (allerdings auch nicht zacko schnell). Allerdings, gibt es eine nette Extension die das Kommando shell hinzufügt. Das ist nett, denn dann hat man eine native Shell in bzr und hat superschnelle reaktionen, Tabvervollständigung überall, etc.
Der Checkout aus SVN hat auch prima geklappt (die Anfangsschwierigkeiten hatte ich vor einem halben Jahr, als ich mir die SVN-Python-Bindings selber bauen musste. ARGH war das ein Kampf.) Jetzt hatte ich sie aber schon und mir auch schon die notwendigen Wrapper-Skripte gebaut die die Library dann halt noch dazuladen.
Well, was soll ich sagen: pull vom SVN war hervorragend, lokales arbeiten auch, aber das Push.. das stirbt immer mit Fehler 175008 (ernsthaft!) und wirft mir dann noch an den Kopf das irgend eine property nicht angewendet werden konnte. Wenn er wenigstens sagen würde welche Property das Problem ist.. Aber naja.
Fazit: Sehr poliert. Gerade im Vergleich zu meinem letzten Test ist die Dokumentation viel besser geworden, das ganze Tool wirkt durchdacht. Vor allem der Output der Kommandos hat mir gefallen, schön aufgeräumt und übersichtlich. Dann ist da natürlich die Tatsache das dieses Tool doch immer noch das einzige ist, das tatsächlich Verzeichnisse auch Versionieren kann und mit renames vernünftig umgeht. Ahh.... Endlich ohne scheu refaktorn. :-)
HG
... will ich eigentlich schon länger mal benutzen, aber es hat mir bisher immer nur zu ein paar kleinen Experimenten gereicht. Allerdings: Felix hat sich schon anstecken lassen und verwendet das jetzt nahezu ausschließlich.
Well, mein Testcase hat leider gar nicht Funktioniert. Einigen Anmerkungen hatte ich entnommen das HG jetzt auch auf SVN zurückschreiben kann herausgefunden wie das geht, hab ich aber leider nicht. Oh well.
Fazit: Schnell, gute Bedienung und Python - aber ungeeignet um damit gegen SVN Repositories zu Arbeiten.
Fazit Fazit
So, dann bleibt mir also die Wahl: entweder GIT zu akzeptieren um damit gegen SVN zu arbeiten, oder aber den Bug in BZR zu finden um dann damit zu Arbeiten.
Vom Bauchgefühl her würde ich mich eigentlich lieber an BZR heranmachen. Mögen tue ich HG am liebsten, das hat einfach das einfachste Design und auch noch eine sehr gute Integration in das System - so öffnet es zum Beispiel standardmäßig gleich das System Merge-Tool (opendiff) anstatt CVS like Konflitkmarker in der Datei zu verstreuen.
So macht man dass.
BZR ist auf jeden fall mein zweiter Favorit - auch Python (kann ich also Hacken) und schön durchdacht - wenn auch manchmal etwas verbose zu bedienen (pull z.B. macht kein merge, aber er sagt einem dann das man statt pull merge machen müsste. ???)
GIT wirkt wie eine mächtige Kanone - ja man kann damit auch auf Spatzen schießen - ja danach wären sie tot - aber muss man sich das wirklich antun, das jeder normale Usecase ein wenig Komplizierter zu handhaben ist als mit den anderen Tools, nur damit man im zweifelsfall auch den Linux-Kernel mit dem gleichen Tool Maintainen kann?
Ich jedenfalls beantworte diese Frage für mich mit einem klaren nein. Und werde mich jetzt erstmal auf bzr und hg werfen.
