HG, BZR und GIT

written by Martin HĂ€cker on

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

BZR

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