Ich fang ja nur langsam an zu verstehen wie sich die verschiedenen Konstrukte unterscheiden.
Da wäre zum Beispiel das immer wieder auftretende Problem das man an Sourcen arbeitet, auf die man nicht comiten kann oder will.
Also zum Beispiel an Bugfixes für ein Projekt, von dem man zwar die Sourcen hat, das aber dooferweise einer Firma gehört die keine comits zulässt. Ah well.
In Git löst man das, indem man das einfach brancht und bei einem neuen Release mit rebase seine Changes auf die neue Plattform hebt. Mercurial und Bazaar lösen das anders, dort gibt es spezielle Plugins Mercurial Patch-Queues und Bazaar Looms die ein Quilt ähnliches Interface bieten um das Problem zu lösen.
Tja, was macht den Unterschied aus?
Eine Sache die mir allmählich aufgeht ist das Teilen dieser Änderungen. Macht man einen Branch und rebased dann immer wieder auf die originalen Sourcen. Das ist super, weil es kein neues Konzept braucht und somit relativ simpel. Aber man kann diesen Branch so gut wie nicht mit anderen leuten Teilen - schließlich verändert man ständig die History. Also doof für die Zusammenarbeit an so einem branch.
Mercurial Patch-Queues sind da besser geeignet - mit dem unterschied das sie extra sind und nicht versioniert werden. Damit kann man sie aber auch nicht teilen.... :) - Das wiederum lässt sich hacken, indem man einfach in dem repository in dem ordner in dem die patch-queue liegt wiederum ein eigenes hg-repository eröffnet. Ein Hack - aber er löst das Problem auf elegante Art und Weise.
Bazaar scheint das mit dem looms am besten gelöst zu haben - die lassen sich nämlich ganz normal im repository pushen - sind aber eben nicht teil der history und führen daher nicht zu den üblen merge-conflikten die man in git erhält.
Auf mich wirkt das so, als zeigen sich die verschiedenen Ideologien der Entwicklungsteams in diesen Entscheidungen: GIT:: KISS - kein neues Konzept (Quilt) ohne das es absolut sein muss, gleichzeitig aber die Linux-Poweruser Mentalität: Wenn du deine History-Verändern willst, dann mach doch, wirst schon wissen was du willst. HG:: Gutes Design, history verändern ist evil - daher musste es was anderes sein. Gleichzeitig ist man aber so stolz auf die Binary- und Wire-Formate, dass man sie nicht verändern darf - daher bleibt die Information aus dem Repository ausgeschlossen. BZR:: Hier wird vor allem auf die Qualität der Code-Basis geachtet, Veränderbarkeit, Usability und schöne API sind dort am wichtigsten - daher ist es überhaupt kein Problem, das die looms natürlich im repository und damit push-bar sind.
Mir ist unklar wie ich das gegeneinander abwägen kann - jede der Mentalitäten hat ihre eigenen Vor- und Nachteile. Zum Beispiel ist mir BZR immer noch zu Langsam um es im täglichen gebrauch einzusetzen - es macht schlicht keinen Spaß.
Andererseits erinnert es mich stark an das alte Mantra: "First make it work, then make it fast!". Also vielleicht wird es doch noch?
p.s.: Ich weiĂź natĂĽrlich das es Stacked-GIT gibt - aber soweit ich das feststellen konnte, ist das nicht der "recommended way of doing things" in der GIT community.
