Verständnissfrage zu Mercurial (TortoiseHg)

[Mavarik]

Hallo!

Ja ich habe auf Mercurial (TortoiseHg) umgestellt. Danke erst mal an alle die mit Nachdruck mich dazu gebracht haben.

Folgendes Problem im Workflow stellt sich mir jedoch, vielleicht mache ich etwas falsch?

Gegeben sei die Datei "Datei.pas". Diese Datei ist bei User A und bei User B GLEICH!

User A macht Änderungen an "Datei.pas" (Revision 20)
User B schick A Dateien per eMail inkl. "Datei.pas" die von User B nicht geändert wurde.
User A checkt die Änderungen die per eMail gekommen sind in einen eigenen Zweig aus. (Revision 21)
User A arbeiten in seien Zweig weiter bis Revision 27
Jetzt soll der Zweig von User B mit User A zusammengefügt werden.
Leider ist nach der Zusammenführung der Inhalt der "Datei.Pas" der von User B und nicht der von User A (Ich gehe davon aus, weil die Revisionsnummer der Datei im Zweig von User B höher ist als die letzte Änderung von User A.

Frage: Wie kann ich Mercurial mitteilen, dass obwohl eine Datei in einem Zweig mit höherer Revisionsnummer geändert wurde, beim zusammen führen die Datei des Zielzweiges übernehmen soll die von Änderungsdatum neuer ist?

oder

Frage: Wie bringe ich Dateien in mein Repository (aus anderen Quellen z.b. per Download) unter, so das das Änderungsdatum nicht die Revisionsnummer für eine Zusammenführung genommen wird?

Mavarik

[Elvis]

Du solltest diesen 2. Branch von der Stelle aus machen, von der User B angefangen hat zu arbeiten. Sonst bekommst du gar nicht alle potentiellen Konflikte mit.

In dem Fall gäbe es für HG ja auch keine Änderungen und er müsste beim Merge auch nix auf einen alten Stand bringen.

Es ist ja auch rein vom logischen Standpunkt aus einfacher nachzuvollziehen, wenn man den Branch da setzt als dein Kollege er die Dateien von dir bekommen hat. Nicht nur um Mercurial einen Dienst zu erweisen.

[Mavarik]

Zitat von Elvis:

Du solltest diesen 2. Branch von der Stelle aus machen, von der User B angefangen hat zu arbeiten. Sonst bekommst du gar nicht alle potentiellen Konflikte mit.

Das hab ich ja, aber der Ur-Branch wurde in der Vergangenheit schon mit meinem zusammengeführt.

[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.