Verständnissfrage zu Mercurial (TortoiseHg)

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

[Mavarik]

Zitat von Uwe Raabe:

... 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 von Mavarik:

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 hg strip 16 die entsprechende Revision löschen. Danach kannst du den Vorgang in korrekter Form wiederholen.

Vorher sicherheitshalber das Repo clonen!

[Mavarik]

Zitat von Uwe Raabe:

Wenn es genau so aussieht (keine von Rev 16 abhängige Changesets), dann kannst du mit 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"