Anstatt das udev Problem zu lösen, ist Scott James Remnant damit beschäftigt über Versionskontrollsysteme zu fluchen.

Er trifft es sehr gut, wenn er sagt, dass er solche Systeme gar nicht benutzen will. Aber es ist ein nötiges Übel wenn man Software entwickelt.

Er nennt eine Liste von Aktionen, für die ein Softwareentwickler ein Versionskontrollsystem braucht. Je mehr überflüssige Kommandos es gibt oder je mehr zusätzliche Parameter man den Kommandos mitgeben muss, umso höher steigt der Hass Index für das jeweilige System.

Ganz besonders verhasst ist für ihn das Kommando add. Er will nicht jede neue Datei einzeln hinzufügen müssen. Ich muss auch sagen, dass dafür ein Kommandozeilen System auch wenig Benutzerfreundlich ist, wenn man jeden Dateinamen einzeln eintippen muss. Dafür ein GUI nützlicher.

Ich persönlich habe sehr viele Dateien im Ordner der Versionskontrolle, die ich nicht versionieren will, von daher bin ich persönlich dafür ein add Kommando zu haben.

Folgende Aktionen nennt er als relevant: get, commit, push, pull, review, merge, log, diff und show.

Wenn ich mir seine Erläuterungen durchlese, merke ich, das Mercurial auf seiner Hass Liste eigentlich nicht sehr weit oben sein dürfte, denn für die genannten Aktionen stehen einfache und intuitive Kommandos zur Verfügung.

Get - Eine Kopie eines Quellcodes erstellen, um daran Veränderungen vorzunehmen. hg clone http://hg.mozilla.org/mozilla-central

Commit - Die aktuellen Änderungen speichern. hg commit -m"Kommentar". Falls nicht jede Datei einzeln hinzugefügt werden sollte, benutzt man hg commit -A -m"Kommentar", das ist nicht wirklich viel Aufwand.

Push - Die eigene Kopie des Quellcodes veröffentlichen. Das ist leider ein komplizierteres Thema. Ein hg push funktioniert nur, falls bereits ein Server installiert ist. hg clone ./ ssh://swatinem.de/var/www/hg/bla schiebt die Änderungen auf einen entfernten Server. Dennoch braucht man dafür leider einen konfigurierten Apache. hg serve erstellt temporär einen eigenen Webserver. Nun muss man allerdings die eigene IP benutzen um an die Daten zu kommen.

Pull - Das ist ein einfaches hg pull -u. Leider wird es komplizierter, sobald man selbst Änderungen seit dem letzten pull gemacht hat. Dann wird ein hg pull && hg merge daraus.

Review - Ein hg incoming listet die Änderungskommentare auf. hg incoming -p zeigt auch die Änderungen selbst an.

Merge - das selbe wie Pull eigentlich.

Log - hg log oder hg glog

Diff - hg diff

Show - hg export tip, wobei tip immer die aktuellste Version ist. Oder eben eine andere Version.

Ganz einfach ist Mercurial nun auch wieder nicht. Aber ich schätze mal, dass man gut damit zurecht kommen kann.

Ich benutze Mercurial leider in einem komplizierteren Szenario. Ich arbeite mit Patches, die ich zwischendurch ändern, aufsplitten und zusammenführen will. Außerdem will ich die Patches immer aktuell haben. Mercurial Queues, mq, macht es mir da nur bedingt einfach. Vor allem die Aufgabe Patches aktuell zu halten ist ein sehr komplizierter Prozess und sorgt immer wieder für Ärger.