Wie kann man nicht festgeschriebene Änderungen in einem lokalen Quecksilber-Repository behalten, während ich noch drücke / ziehe?

Question

Wenn ich an einigen Dateien arbeite, die ich nicht festschreiben möchte, speichere ich sie einfach. Ich habe dann andere Dateien, die ich auf den Server übertragen möchte. Wenn jedoch jemand anderes Änderungen am Repository vorgenommen hat und ich sie herunterziehe, werden Sie aufgefordert, sie zusammenzuführen oder neu zu starten. Aber eine dieser Optionen führt zu mir um meine lokalen Änderungen zu verlieren, die ich nicht festgeschrieben habe .

Was machen andere Leute, um das zu umgehen? Ich finde die Dokumentation für die Regalerweiterung schwierig, mich zurechtzufinden.

Hinweis: Ich verwende Mercurial Eclipse, um Dateien zum / vom Server zu verschieben und von diesem zu ziehen.

Jede Erklärung hierfür wäre sehr dankbar! Danke!

---

Beispiel:

Ich arbeite an meiner Website in Mercurial Eclipse. Ich habe einen neuen Ordner und neue Dateien, die ich noch nicht auf den Server übertragen möchte. Ich habe auch einige vorhandene Dateien geändert und möchte diese Änderungen noch nicht live übertragen.

Dann bricht etwas auf meiner Website zusammen und ich muss es reparieren. Dadurch kann ich es nicht reparieren, ohne es neu zu gründen oder mit dem neuesten Tipp des Repos zu verschmelzen. Dadurch verliere ich alle nicht festgeschriebenen Änderungen.

Was soll ich mit meinem neuen Ordner und den Dateien tun, die ich bearbeitet habe, wenn ich ihn nicht verlieren möchte? Das erneute Klonen scheint mühsam. Das Kopieren der Dateien in einen neuen Ordner erscheint ebenfalls mühsam. Ich bin mir sicher, dass Shelving oder MQ tun werden, was ich will. Ich weiß nur noch nicht, wie ich es anstellen soll.

Answer 1

Ich bin sicher, jemand wird Ihnen helfen, eine schlechte Problemumgehung zu finden, aber der beste Weg ist, Ihre Ziele zu ändern - verpflichten Sie sich einfach.Code, der nicht festgeschrieben wurde, wurde nicht geschrieben.Wenn Sie es nicht ertragen können, häufige Festschreibungen in Ihrem Verlauf zu haben, verwenden Sie Mercurial Queues mit einem Warteschlangen-Repository und schreiben Sie diese fest.Sie können dann die Änderungssätze einfügen, drücken / ziehen / zusammenführen und wieder einschieben, und Ihre gesamte wertvolle Arbeit wird in der Patch-Warteschlange festgeschrieben.

Answer 2

In Bezug auf Ihre Beispielsituation würde ich Folgendes tun (gemäß Ry4ans Strategie, nur die Dinge festzuschreiben, an denen Sie gerade arbeiten, die Sie aber noch nicht veröffentlichen möchten):

Angenommen, Sie beginnen in einem Repository wie diesem zu arbeiten:

$ hg status -A
C f1
C f2
$ hg glog
@  changeset:   1:7f3c6c86a92f
|  tag:         tip
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

Das heißt, es gibt 2 Dateien und 2 Commits / Änderungssätze. Sie erledigen einige Arbeiten, fügen Sie beispielsweise eine neue Funktion hinzu, und dann sieht Ihre Arbeitskopie möglicherweise folgendermaßen aus:

$ hg status
M f2
? f3
? f4

Es gibt 2 neue und 1 geänderte Datei. Jetzt müssen Sie einen Fehler beheben, für den Sie auch neue Änderungen in einem Remote-Repository benötigen. Erstellen Sie eine Momentaufnahme Ihrer aktuellen Arbeit, indem Sie sie festschreiben und die Remote-Änderungen abrufen (in der Reihenfolge, in der Sie dies tun, spielt dies keine Rolle, ein Pull berührt standardmäßig nicht den Status Ihrer Arbeitskopie):

$ hg commit -A -m "snapshot feature work"
$ hg pull

Dies kann zu einem Verlauf wie dem folgenden führen:

o  changeset:   3:2284ba62de07            <-- just pulled in
|  tag:         tip
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| @  changeset:   2:4a19d371a04f          <-- your interrupted work
|/   summary:     snapshot feature work
|
o  changeset:   1:7f3c6c86a92f
|  summary:     add f2
|
o  changeset:   0:03ca1e6d5b86
   summary:     initial

Jetzt können Sie Version 3 aktualisieren / auschecken und Fehler beheben:

$ hg update 3
.. fix the bug ..
$ hg commit -m "fix a bug"
$ hg glog --limit 3
@  changeset:   4:5d3d947fb4af
|  tag:         tip
|  summary:     fix a bug
|
o  changeset:   3:2284ba62de07
|  parent:      1:7f3c6c86a92f
|  summary:     edit f1
|
| o  changeset:   2:4a19d371a04f
|/   summary:     snapshot feature work
:

Sieht gut aus, lassen Sie uns Ihr Update vorantreiben, d. h. es live schalten, ohne Ihre Zwischenarbeit zu veröffentlichen:

$ hg push -r 4

Dadurch werden alle Änderungen übernommen, die zu Revision 4, Ihrem Bugfix, führen, jedoch keine anderen Zweige in Ihrem lokalen Repository. Sie können auch -r . verwenden, der sich auf die übergeordnete Revision Ihrer Arbeitskopie bezieht, d. H. Auf die gerade festgeschriebene Revision.

Schließlich können Sie zu Ihrer Feature-Arbeit zurückkehren und Ihre Arbeit fortsetzen:

$ hg update 2
.. work, commit, work, commit ..
.. finally merge with the other branch, e.g. revision 4

Diese Schritte befinden sich in der Befehlszeile, aber ich denke, es ist nicht zu schwierig, das allgemeine Konzept an die entsprechenden Klicks im Eclipse Mercurial-Plugin anzupassen.

Einige zusätzliche Hinweise:

• Möglicherweise möchten Sie Ihr Snapshot-Commit mit einem Lesezeichen versehen , damit Sie nicht mit Revisions-IDs oder -Nummern arbeiten müssen.
• Wenn Sie Ihre Feature-Arbeit später in einem einzigen Commit veröffentlichen möchten, verwenden Sie die Erweiterung Zusammenbruch , wenn Sie fertig sind.