Dennis Heidsiek wrote: > Wie bereits gesagt bin ich der Ansicht, das sich Mercurial und Git in > der Bedienung nicht so sehr voneinander unterscheiden; und gewisse > Schwierigkeiten vom Umstieg von SVN auf ein DVCS sind (leider) einfach > nicht zu vermeiden, einfach da sich hier ganz neue Arbeitsabläufe > eröffnen.
Der einzige wirkliche Fehler den ich bisher (selbst bei einem Computer-DAU) mit Mercurial erlebt habe, ist zu vergessen zu pushen oder zu pullen (solange keine als experimentell ausgezeichnete Module genutzt wurden). Selbst einen merge habe ich letztens über’s telefon erklaärt, und das komplizierteste war, dass ich kein TortoiseHG nutze, der andere aber schon (finden der richtigen Tasten :) ). (auf der Kommandozeile wäre es noch einfacher gewesen) > Aber auch Git kann man wie ein SVN bedienen … man kann sogar > auf ein SVN zugreifen :). Wie mit hgsubversion (Mercurial extension die ähnliche Strukturen nutzt wie hg-git) :) >> Doch: Das Mercurial Plugin funktioniert auch in die andere Richtung: > > Klar, das Plugin selbst funktioniert bidirektional und kann die beiden > Formate ineinander unwandeln aber es liegt eben nur für hg- und nicht > für git-Clients vor (das meinte ich). Jupp, aber es ändert nichts wesentliches am workflow (man muss halt einen Mercurial aufrufenden hook in seinem lokalen git repo erstellen :) ). >> Mercurial baut auf jedem System auf dem auch git baut […] in Python[…] >> geschrieben > > <humor>Das wäre dann wieder ein Punkt für Git: “Python? That is for > children. A Klingon Warrior uses only machine code, keyed in on the front > panel switches in raw binary.” ;)</humor> ;) > Ich finde das doch recht witzig, wir finden den selben Aspekt wichtig, > aber sind zu genau entgegengesetzten Einschätzungen gekommen. An der > Git-Datenstruktur schätze ich, dass sie auf der untersten Ebene recht > simpel ist und gleichzeitig jede Redundanz vermeidet – vielleicht sind > deshalb die git-Repositories im Allgmeinen die Kleinsten (ja, ich habe > hier mal wieder ein git gc vorausgesetzt). Was ich im Gegenzug bei Mercurial schätze ist, dass die Struktur genau für ihre Aufgabe optimiert ist. Sie ist sogar auf Zugriffsstruktur von Dateisystemen optimiert: Daten sind im store in einem Dateibaum, der dem Arbeitsverzeichnis entspricht, weil sich so beim sortierten Auslesen (das machen die meisten Dateisysteme) der Festplattenkopf am wenigsten bewegen muss. Deswegen ist auch bei einem update via Mercurial die Platte sehr viel leiser als bei git (ich höre das deutlich; meine Platte rattert). Und deswegen sind git repos kleiner. hey, und ich kann gerade den Zirkelschluss zu Tastaturbelegungen ziehen: Ein Layout, das nur auf Tastenpositionen und Fingerwiederholungen achtet, hat (bei maximaler Optimierung) gezwungenermaßen bessere Tastenpositionen und weniger Fingerwiederholungen als eins, das zusätzlich beachtet, dass nicht erst ein Finger oben und dann der direkt daneben unten eingesetzt wird. Welches von ihnen besser zum Tippen ist, hängt von der Flexibilität der Finger ab :) > Eigentlich arbeitet Git da recht ähnlich, in den Packfiles gibt es auch > unkomprimierte Schnappschüsse, Deltakodierung und Indizierung für einen > schnelleren Zugriff. Der Unterschied ist halt, dass das bei Mercurial direkt beim committen on- the-fly passiert. Aber sie haben auch beide immer wieder voneinander gelernt – was ich sehr gut finde! > Ich glaube, in dieser Frage werden wir einfach > nicht zueinander finden … einigen wir uns darauf, das wir uns uneinig > sind :). Ich denke, da werden wir nicht drum rum kommen. Immerhin sind wir aber bereits fast an der untersten Ebene (statt „A > B ⇒|⇐ B > A“ sind wir bei „A macht das so, was ich wegen X besser finde als das, wie B es macht ⇒|⇐ Mir ist aber Y wichtiger als X, und das kann B besser“), so dass die Diskussion, finde ich, fruchtbar und sinnvoll war – und auch einen schönen Abschluss hat. > Und ich würde keinen Distributions-Maintainern glauben, die glauben > kompetenter als die eigentlicher Software-Maintainer zu sein ;): “The > latest stable Git release is v1.7.1.” (http://git-scm.com/). Ich schon. Die distributions-maintainer sehen nämlich ein viel breiteres Bild als die Software-Entwickler. Sie testen gegen die verschiedensten setups und binden oft noch patches ein, um alles zum Laufen zu kriegen. > Dann hat Dir die neue Version doch etwas gebracht, > #Friede_Freude_Eierkuche :). Sie wird mir was bringen, wenn sie stable wird :) (am Anfang war die wohl noch > /richtig/ mies im Vergleich zu Mercurial), Auch ohne den Vergleich, ja :) > wobei ich niemanden empfehlen > würde, Git oder auch Mercurial ausſchließlich über die Manpages zu > lernen. Dafür gibt es einfach viel zu viele, und man kann sich ja wohl > kaum alphabetisch durchlesen … besser ist es da, mit einem guten > Tutorial anzufangen. Stimmt. Warum haben wir eigentlich kein `tut git` und `tut hg` als Erweiterung zu `man git` und `man hg`? Ein standard tutorial-viewer wäre toll! >> Nebenbei: Hast du gemerkt, dass auf einem deutschen System der Großteil >> der Ausgabe von Mercurial auf Deutsch ist? > > Erst jetzt, wo Du es sagst :). Wobei ich kein Problem mit Englisch habe, > und bei Kommandozeilenbefehlen sogar lieber englischſprachige Manpages > lese, einfach weil ich mir dann die Abkürzungen besser merken kann – rm > -f steht ja für “remove --force”, und nicht für löschen --erzwingen. Die Namen der Befehle sind nicht übersetzt, nur die Beschreibungen. „-C --clean Entferne nicht versionierte Änderungen (kein Backup)“ Ist also genau so wie ich es sinnvoll finde, und mMn für nicht-Programmierer ein nicht zu unterschätzender Vorteil – immerhin entwickeln wir ein Layout für die deutsche Sprache, da kann es auch mal sein, dass jemand dabei ist, der kein Englisch kann :) Liebe Grüße, Arne
