Hg Flow

Während der Beschäftigung mit dem vor ein paar Tagen erwähnten Git-Flow kam mir die Idee, das Modell auch auf Mercurial anzuwenden. Gut dass ich zunächst nach dem Stichwort „hg flow“ gesucht habe! So stieß ich auf das Projekt hgflow. Ich habe noch keine Erfahrung damit gesammelt, denke aber, dass es eine gute Umsetzung darstellt. Einen ausführlichen (englischen) Text dazu gibt es im Wiki des Projektes selbst. Ähnliche Artikel:ProjektarbeitPyDay: Erste SchritteEclipse, das Schweizer Offiziersmesser für den EntwicklerHg Update NullFinde den Übeltäter!

PyDay: Erste Schritte

Wenn ich mit einem neuen Projekt beginne, richte ich mir zunächst meine Arbeitsumgebung ein. Neben dem (hoffentlich nur einmaligen) Einrichten von Eclipse mit den Plugins PyDev, MercurialEclipse, MyLyn und dem MyLyn-Bitbucket-Connector sind noch einige Arbeiten notwendig, um mit einem neuen Projekt beginnen zu können. Eclipse macht es uns recht einfach, wenn man weiß, wo man suchen muss. Die folgenden Schritte sind lediglich eine Empfehlung meinerseits und müssen nicht sklavisch befolgt werden. Lasst mich wissen, falls ihr einen eleganteren Weg gefunden habt. Zunächst wollen wir ein neues PyDev-Projekt anlegen und es unter Quellcodeverwaltung nehmen. Im nächsten Artikel richten wir dann dasHier geht's weiter … PyDay: Erste Schritte

Hg Update Null

Neben dem Kommandozeilenbefehl „hg update null“ kann man das selbe durchaus auch über die grafische Oberfläche erreichen. Geben Sie in TortoiseHg im Update-Dialog einfach das Wort „null“ in das Feld ein, wo normalerweise die Changeset-Nummer steht: Dies ist aber bitte nicht zu verwechseln mit „hg update 0„, das auf das allererste Changeset in dem Repository updaten würde. Dies bewirkt übrigens, dass alle Arbeitsdateien aus dem Arbeitsverzeichnis gelöscht werden. Übrig bleiben Dateien, die nicht unter Kontrolle von Mercurial stehen und folglich auch deren Verzeichnisse. Ebenfalls bleibt das Verzeichnis „.hg“ übrig, aber das muss ja auch sein, denn dies ist ja dasHier geht's weiter … Hg Update Null

Finde den Übeltäter!

Aufgabenstellung Eine Funktion hat schon mal wunderbar funktioniert. Irgendwann in der Zwischenzeit der Entwicklung ist der Aufruf aber verschwunden. Leider hat das damals keiner gemerkt. Wir haben aber herausgefunden, dass in einem bestimmten Changeset noch alles in Ordnung war, in einem späteren jedoch nicht mehr. Annahme Die Prüfung lässt sich mittels eines einfachen „grep“ durchführen. Grep liefert einen Return Code 0, wenn etwas gefunden wurde, und einen Return Code 1, wenn nichts gefunden wurde. Suchen wir nach dem Ereignis „MouseMove“ (wenn wir wissen, dass dieses nur an dieser einen Stelle verwendet wurde), dann kann Grep die meiste Arbeit für unsHier geht's weiter … Finde den Übeltäter!

Hg: Suche im gesamten Repository

Aufgabenstellung: Suche in allen Klassen in allen Revisionen nach Stellen, wo „MeineVariable“ verändert wurde. Befehl: D:\Projekte\MeinProjekt> hg grep –all -l -n „MeineVariable“ *.cls –all: Zeigt alle zutreffenden Revisionen -l: Zeigt nur zutreffende Dateinamen und Revisionen -n: Zeigt zutreffende Zeilennummern Das Ergebnis könnte dann so aussehen: MeineKlasse.cls:94:38:- MeineKlasse.cls:1:38:+ Der Bezeichner „MeineVariable“ wurde also in der gesamten Historie nur in einer Klasse verändert und dort in den Changesets 1 und 94 verändert. „+“ und „-“ am Ende beziehen sich auf die übliche Notation im Diff. Um nun genau zu erfahren, was verändert wurde, kann man sich die Changesets dann einzeln anschauen. [btcpaymentsHier geht's weiter … Hg: Suche im gesamten Repository

Merge-Konflikte manuell auflösen

Merge-Konflikte bedeuten Arbeit, denn wo die Automatik versagt, muss der Mensch ran. Angenommen, zwei Entwickler arbeiten an dem selben Feature und kommen mehr oder weniger auf die selbe Idee, was dann von beiden eine Änderung in derselben Quellcode-Zeile zur Folge hat. Wenn dann später eine Zusammenführung dieser beiden Entwicklungslinien erfolgt, wird es unweigerlich zu einem Konflikt kommen, da Mercurial nicht beide Änderungen eigenständig durchführen kann. Üblicherweise wird in diesem Zusammenhang von einem Three-Way-Merge gesprochen. Bei einem Drei-Wege-Merge wird die den beiden zu verschmelzenden Köpfen (im Bild unten sind dies „B“ und „C“) gemeinsame Basisrevision der Datei als dritte Revision hinzugezogenHier geht's weiter … Merge-Konflikte manuell auflösen

Ungewolltes Branching in Mercurial

Sobald mehrere Leute an derselben Sache arbeiten, kann es zu Konflikten kommen. Im Rahmen dieses Artikels soll diese triviale Erkenntnis allerdings nicht den zwischenmenschlichen Aspekt beleuchten. Es sind hier rein technische Konflikte beim Zusammenführen zweier Dateiversionen in Mercurial gemeint. Wir betrachten hierbei die beiden Kollegen Max und Moritz, die treffenderweise an der Erfassung des gleichnamigen Gedichtes von Wilhelm Busch arbeiten. Leider haben sie sich nicht so recht abgestimmt, wer welche Strophe eintippen soll, so dass es gleich zu Beginn zu einer Überschneidung kommt. Zunächst beginnt alles ganz harmlos. Max fängt mit dem ersten Streich an, beendet ihn, dann clont MoritzHier geht's weiter … Ungewolltes Branching in Mercurial