Verständnissfrage zu Mercurial (TortoiseHg)

[Uwe Raabe]

Irgendwie habe ich noch nicht verstanden, was da genau abgelaufen ist. Insbesondere der Schritt 3 ist mir noch nicht klar.

Sind die Dateien als Email-Patch geschickt worden oder ganz normal die einzelnen Dateien als Anhang an eine Email? Quasi analog zum Kopieren der Dateien über einen USB-Stick?

[Namenloser]

Ich habe dein Problem auch nicht so ganz verstanden. Das Änderungsdatum ist für die Zusammenführung (Merge) eigentlich völlig unerheblich.

Denke immer daran, woraus die Revisionen bestehen: Das sind Diffs zu einer vorhergehenden Version. Das Diff entspricht quasi dem Edit.

Bei einem Merge werden jetzt alle Edits zusammengefügt, das heißt, es werden vom Ausgangspunkt aus erst alle Diffs des einen Branches angewendet, und dann alle Diffs des zweiten Branches (zumindest kann man es sich so vorstellen). So erhält man dann eine Datei, die alle Edits, die in beiden Branches gemacht wurden, beinhaltet – theoretisch. Manchmal kommt es natürlich zu Konflikten. Um diese zu lösen, gibt es von Mercurial zum Teil Heuristiken, aber oft bleibt einem nichts anderes übrig, als die Konflikte manuell zu beheben.

Mir war das ganz am Anfang auch noch nicht ganz klar, aber im Grunde ist ein Merge auch nur ein ganz normales Commit. Du hast also 100% Einfluss darauf, was übernommen wird. Prinzipiell kann das Merge-Commit am Ende auch völlig andere Daten enthalten als die beiden Quellversionen... wäre nur halt nicht sinnvoll .

TortoiseHG zeigt dir, wenn es beim Merge Konflikte feststellt, alle beteiligten Dateien in einer Liste an. Du kannst dann auswählen, was wie du verfahren willst: Du kannst die Heuristik von HG darauf anwenden, du kannst aber auch sagen, „übernimm nur meine Datei und vergiss die andere Version“ oder du kannst sagen „übernimm nur die andere Datei und vergiss meine“. Wenn du nur die neuere Datei erhalten willst und die alte verwerfen willst, dann wähle einfach eine dieser beiden Optionen. Das ist oft bei Binärdateien das einzig sinnvolle.

Falls du aber die Änderungen aus beiden Dateien erhalten willst, und die Heuristik die Konflikte nicht auflösen konnte, dann musst du selbst ran. Wähle „Tool Resolve“. Das startet in der Regel TortoiseDiff oder KDiff3.

In beiden Programmen ist dein Bildschirm dreigeteilt: Auf der einen Seite ist die Version des einen Branches, auf der andereren die Version des anderen Branches, und in der Mitte bzw. unten ist die zusammengeführte Version. Stellen, an denen sich Konflikte befinden, sind hier mit roten Fragezeichen markiert (zumindest bei TortoiseDiff).

In den Ansichten für die Quelldateien aus den Branches, kannst du Zeilen selektieren und dann mit Rechtsklick im Kontextmenü dem Tool sagen „diesen Textblock übernehmen“. Dann wird der Teil im unteren bzw. mittleren Fenster an der entsprechenden Stelle eingefügt.

Du kannst aber auch den Text der gemergeten Version manuell editieren, indem du einfach das Fenster fokussierst und wie in einem normalen Texteditor darin rumeditierst.

Am Ende musst du den gemergeten Text noch speichern (Strg+S). Dann kannst du das Tool schließen und Mercurial mitteilen, dass du den Konflikt behoben hast. Wenn ich mich nicht irre, ging das, indem du im Explorer (oder welchen Dateimanager du auch benutzt) zur entsprechenden Datei navigierst, das TortoiseHG-Kontextmenü aufrufst und dort die entsprechende Option auswählst.

Wenn du alle Konflikte behoben hast, dann machst du ein Commit.

[Mavarik]

Zitat von Uwe Raabe:

Irgendwie habe ich noch nicht verstanden, was da genau abgelaufen ist. Insbesondere der Schritt 3 ist mir noch nicht klar.

Sind die Dateien als Email-Patch geschickt worden oder ganz normal die einzelnen Dateien als Anhang an eine Email? Quasi analog zum Kopieren der Dateien über einen USB-Stick?

Genau... Als Anhang wie per UPS-Stick..

@Namenloser Danke für Deine ausführliche Anleitung! Das habe ich schon verstanden.

Mein Problem ist, dass ich, obwohl ich die Version der "Datei.pas" als letzter editiert habe, diese Datei bei mergen aus dem anderen Brach überschrieben wird.

[Namenloser]

Es ist immer noch recht abstrakt, wenn man die entsprechende Datei nicht vor sich hat. Welches Problem entsteht denn konkret dadurch, dass die andere Datei „übernommen“ wird? Ist dadurch Code, den du hinzugefügt hast, verloren gegangen? Oder hast du vielleicht Ballast-Code ausgemistet und er ist jetzt wieder drin?

Und hat Mercurial beim Merge überhaupt einen Konflikt angezeigt oder ging der Merge von vornherein automatisch durch? Sind Bedienfehler ausgeschlossen? Könnte ja sein, dass du versehentlich im Konfliktfenster voreilig einen der Buttons gedrückt hast . Dass Mecurial von alleine einfach Änderungen überschreibt, kann ich mir eigentlich nicht vorstellen. Es sei denn, die Datei wäre im Binärmodus, aber dann hätte imo die aktuellere Version übernommen werden müssen.

Generell denke ich jedenfalls nicht, dass die Revisionsnummer direkt etwas damit zu tun hat.

[Mavarik]

Zitat von Namenloser:

Es ist immer noch recht abstrakt

OK Nochmal!

gegeben ist ein Verzeichniss mit 400 *.pas Files.

Die "Datei.Pas" hab ich bearbeite und bearbeitet und bearbeitet...

Dann erhalte ich vom Kollegen einen Zip-File mit diesen 400 Dateien... (Seine Version)
Diese kopiere ich in mein Verzeichnis und Committe diese in einen eigenen Branch.
Dann aktualisiere ich meine Workcopy wieder auf meinen stand und arbeite weiter.
Die "Datei.pas" habe ich das letzte mal vor dem Kopieren der Zip Datei geändert.
Wenn ich 10 Revisionen später dann den Brach merge übernimmt Mercurial die Datei vom Kollegen, da diese Datei eine höhere Revision hat als meine letzte Änderung der Datei. Kein Konflikt!

Wo liegt mein Fehler?

Mavarik

[Namenloser]

Achso, ich glaube jetzt verstehe ich das. Allerdings ist das genau das Verhalten, was ich von Mercurial an der Stelle erwartet hätte.

Code:

Branch mit Version vom Kollegen:             .-> 4 (Dateien mit Dateien vom Kollegen überschrieben) -----.
Dein Branch:                     1 -> 2 -> 3 +-----> 5 -> 6 -> 7 -> 8 -> 9 -> 10 -> 11 -> 12 -> 13 -> 14 +-> 15 (merge)

Die Branches bilden eigentlich parallele Prozesse ab.

Dein Denkfehler besteht darin, dass du die Reihenfolge, in der du die alternativen Realitäten (Branches) manipuliert hast, gleichsetzt mit der zeitlichen Abfolge innerhalb der Realitäten selbst. In Revision 4 hast du Schrödingers Katze umgebracht, dann bist du in der Zeit zurückgereist zu Revision 3, und diesmal hast du seine Katze leben lassen (Revision 5). In welcher Reihenfolge du das gemacht hast und ob du zwischendurch noch einen Kaffee getrunken hast, ist Schrödingers Katze egal, sie kriegt davon auch gar nichts mit .

Um von Schrödinger wegzukommen: Es hätte auch sein können, dass nicht du selbst beide Branches bearbeitest, sondern nur deinen eigenen und ein Kollege den anderen. Dann wäre 3 der letzte gemeinsame Stand gewesen, von dort aus hast du Revision 5 entwickelt und der Kollege Revision 4.

Anschließend wurden beide Branches gemerged. Da der Kollege die Datei nach Revision 3 noch bearbeitet hat, du aber nicht, wird natürlich die vom Kollegen bearbeitete Version übernommen.

[Uwe Raabe]

Zitat von Mavarik:

Die "Datei.Pas" hab ich bearbeite und bearbeitet und bearbeitet...

Ich nehme an, du machst jetzt ein Commit und die Revision bekommt die Nr. 20

Zitat von Mavarik:

Dann erhalte ich vom Kollegen einen Zip-File mit diesen 400 Dateien... (Seine Version)
Diese kopiere ich in mein Verzeichnis und Committe diese in einen eigenen Branch.

Hier ist offenbar das Problem. Das Repo kennt deine Änderungen an der Datei in Revision 20. Der Branch, der hier entsteht basiert auf diesem Stand, bekommt aber eine alte Datei beim Commit untergejubelt. Diese wird dann natürlich als die aktuelle Version behandelt und ist "neuer" als die aus der Revision 20.

Du müsstest eigentlich vor dem Kopieren der Kollegen-Files erst wieder auf den Stand updaten, der dem gemeinsamen Branch entspricht. Dort hat die besagte Datei ja noch den ursprünglichen Zustand und beim Commit wird keine Änderung erkannt. Damit ist deine Version aus Revision 20 die aktuellere.

Ich verwende für solche Synchronisationsarbeiten mit nicht HG-Teilnehmern immer einen eigenen Clone, den ich dann per Push/Pull mit meinem Arbeits-Clone abgleiche.

[Mavarik]

Zitat von Uwe Raabe:

Ich verwende für solche Synchronisationsarbeiten mit nicht HG-Teilnehmern immer einen eigenen Clone, den ich dann per Push/Pull mit meinem Arbeits-Clone abgleiche.

OK... Also erst die lokale Kopie committen dann auf den letzten Stand (Merge/Commit des Brachnes) zurückstellen und dann die Dateien kopieren?!?

OK das klingt logisch.

Was hilft Dir da die Clone-Kopie? Kannst Du es damit besser steuern?

Mavarik

[Uwe Raabe]

Zitat von Mavarik:

Was hilft Dir da die Clone-Kopie? Kannst Du es damit besser steuern?

Ja, ich habe dann immer den letzten Stand des Remote-Workers in dem separaten Clone und kann direkt seine Änderungen dort einpflegen und committen. Dann hole ich mir mit Pull die Changesets in meinen Arbeits-Clone, die dort als separater Zweig auftauchen. Das kann ich dann entsprechend mergen. Natürlich kannst du das auch innerhalb deines Arbeits-Clones machen, aber man vergisst leicht, auf den passenden Stand zurückzusetzen, bevor man die fremden Dateien rein kopiert.

Ich arbeite sehr extensiv mit lokalen Clones - die kosten ja so gut wie nichts und gehen rasend schnell. Vielleicht schaffe ich es ja in den nächsten Tagen einen Artikel über den Workflow zu schreiben. Warren Postma hat in seinem Blog ja gerade etwas über die Vorzüge von DVCS allgemein und Mercurial im Besonderen geschrieben. Es ist halt alles etwas abstrakt. An konkreten Fällen lernt man das aber besser.