Verständnissfrage zu Mercurial (TortoiseHg)

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