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:

Zitat von Elvis (Beitrag 1240517)

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:

Zitat von Uwe Raabe (Beitrag 1240520)

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:

Zitat von Namenloser (Beitrag 1240599)

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:

Zitat von Mavarik (Beitrag 1240600)

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:

Zitat von Mavarik (Beitrag 1240600)

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:

Zitat von Uwe Raabe (Beitrag 1240606)

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:

Zitat von Mavarik (Beitrag 1240667)

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.

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1240669)

... Es ist halt alles etwas abstrakt. An konkreten Fällen lernt man das aber besser.

Stimmt aber ich glaube ich habs...

Bei den blauen Pfeilen habe ich Dateien eingespielt und beim roten, habe ich vergessen mit der Version weiter zu arbeiten...

"Anfängerfehler"

Im Nachhinein kann man das nicht mehr beheben, oder?

Mavarik

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1240679)

Im Nachhinein kann man das nicht mehr beheben, oder?

Wenn es genau so aussieht (keine von Rev 16 abhängige Changesets), dann kannst du mit

Delphi-Quellcode:

hg strip 16

die entsprechende Revision löschen. Danach kannst du den Vorgang in korrekter Form wiederholen.

Vorher sicherheitshalber das Repo clonen!

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1240680)

Wenn es genau so aussieht (keine von Rev 16 abhängige Changesets), dann kannst du mit

Delphi-Quellcode:

hg strip 16

die entsprechende Revision löschen. Danach kannst du den Vorgang in korrekter Form wiederholen.

Vorher sicherheitshalber das Repo clonen!

Nutze das nie mit Kommandozeile... Muss ich testen...

unknown command: "strip"

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1240682)

Zitat:

Zitat von Uwe Raabe (Beitrag 1240680)

Wenn es genau so aussieht (keine von Rev 16 abhängige Changesets), dann kannst du mit

Delphi-Quellcode:

hg strip 16

die entsprechende Revision löschen. Danach kannst du den Vorgang in korrekter Form wiederholen.

Vorher sicherheitshalber das Repo clonen!

Nutze das nie mit Kommandozeile... Muss ich testen...

unknown command: "strip"

Dann ist die MQExtension offenbar nicht installiert . die wäre dafür nötig.

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1240683)

Dann ist die MQExtension offenbar nicht installiert . die wäre dafür nötig.

Oje noch was neues... Was muss ich installieren, damit das mit TortoiseHg funktioniert?

[Namenloser]

Du kannst auch Revision 17 nachträglich an Revision 16 „dranpfropfen“, mit Rebase.

Vorher aber unbedingt ein Backup (bzw. Clone) vom gesamten Repository machen. Wobei ich es bei Mercurial bisher immer geschafft habe, von mir verursachte Fehler wieder zu beheben (im Gegensatz zu GIT), aber sicher ist sicher.

Zitat:

Zitat von Mavarik (Beitrag 1240685)

Oje noch was neues... Was muss ich installieren, damit das mit TortoiseHg funktioniert?

Viele Extensions werden bei TortoiseHg schon mitgeliefert, man muss sie nur aktivieren. http://mercurial.selenic.com/wiki/UsingExtensions

[Mavarik]

@Uwe Gerade gefunden...

[Namenloser]

Was ist damit? Mit dem Problem hier hat das eigentlich nichts zu tun :gruebel:

Subrepos sind Repositories in Repositories... verwende ich gerne für externe Komponenten/Bibliotheken bei Programmen. Hat Vorteile gegenüber dem Lib-Verzeichnis, weil man immer den kompatiblen Versionsstand hat. Andernfalls kann es ja passieren, dass man mal eine neue Version einer Komponente ins Lib-Verzeichnis kopiert, und dann Wochen später irgendein altes Projekt öffnet, das auch diese Komponente verwendet, und dann plötzlich merkt, dass man Build-Fehler bekommt, weil sich irgendwas an der Schnittstelle geändert hat...

[Mavarik]

Zitat:

Zitat von Namenloser (Beitrag 1241523)

Was ist damit? Mit dem Problem hier hat das eigentlich nichts zu tun :gruebel:

Subrepos sind Repositories in Repositories... verwende ich gerne für externe Komponenten/Bibliotheken bei Programmen. Hat Vorteile gegenüber dem Lib-Verzeichnis, weil man immer den kompatiblen Versionsstand hat. Andernfalls kann es ja passieren, dass man mal eine neue Version einer Komponente ins Lib-Verzeichnis kopiert, und dann Wochen später irgendein altes Projekt öffnet, das auch diese Komponente verwendet, und dann plötzlich merkt, dass man Build-Fehler bekommt, weil sich irgendwas an der Schnittstelle geändert hat...

Uwe und ich hatten eine kleine Skype Session und ich habe heute meine Repos umgebaut… - DEN GANZEN TAG - lol…

Diese Option hatte wir gesucht…

Mavarik

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1241535)

Uwe und ich hatten eine kleine Skype Session und ich habe heute meine Repos umgebaut… - DEN GANZEN TAG - lol…

Diese Option hatte wir gesucht…

Ich bin mir nicht sicher, ob es das ist, was du da rein interpretierst. Die --subrepos Option bewirkt bei manchen Befehlen (z.B. ADD) eine Einbeziehung der SubRepos. Bei vielen Befehlen ist das aber bereits Standard.