Meine Frage entspricht genau der auf StackOverflow: What's the best way to back out multiple changesets in mercurial?. Ich bin zu dumm die Antworten zu verstehen und brauche Eure Hilfe

Meine Frage:

• Ich bin auf einem Zweig der ein neues Feature implementieren soll
• 1/3 der Commits sind Testcode dessen Beschreibung immer mit "Testcode: " anfängt
• Nun bin ich fertig und möchte den Testcode wieder entfernen bzw. rückgängig machen

Ich sehe, ich kann mit hg backout das genaue Gegenteil einer Revision vornehmen um sie somit rückgängig zu machen. Angenommen, mein Verlauf sieht so aus:

markieren

Code:

1 - 2 - [3] - 4 - [5] - [6] - 8 - 8+

Die Nummern in Klammern sind die, welche ich nun rückgängig machen möchte.

Der Befehl hg backout -r 6 würde beispielsweise ein Changeset committen das die Änderung von 6 rückgängig macht. Ich möchte das nicht manuell von Hand machen. Wie kann ich sagen "Tue das für alle Changesets die mit "Testcode: " beginnen rückwärts?

Ein anderer Weg: In TortoiseHg kann ich die Changesets ja direkt finden, markieren und sagen "Copy Selected as Patch". Nun habe ich in einer Diff-Datei, die Änderungen die ich ja gerade rückgängig machen will. Also das Gegenteil von dem, was ich will. Komme ich von hier aus weiter?


Ich habe bislang den Testcode nie committed und das alles auf einem immer weiter anwachsenden Shelf gehabt, aber da verliere ich leider schnell die Übersicht.

Ich kenne mich mit Mercurial nicht aus, aber hier mal meine Gedanken:
Also in Git gibt es die Möglichkeit einzelne Committs von Repo A nach Repo B zu holen (cherry-pick). Sofern es so etwas auch in Mercurial gibt könntest Du einen neuen Branch anlegen und nur die Committs "cherry-picken", die Du behalten möchtest.

Ja, so etwas ginge in Mercurial auch- Aber genau diese Handarbeit möchte ich mir ja sparen.

Aber gute Idee, ein neuer Zweig wäre eine dritte Möglichkeitee. Mal sehen ob ich dort irgendeinen Automatismus finde dem ich sagen kann "Nimm nur die mit welche nicht mit 'Testcode: ' anfangen".

Der Ansatz, den Testcode gar nicht in das Repo rein zu lassen, hat natürlich auch seinen Charme. Dann muss man sich keine Gedanken machen, wie man die ChangeSets später wieder raus bekommt.

Ich weiß jetzt nicht, was man sich jetzt genau unter diesem Testcode vorstellen muss, aber so aus der Hüfte fallen mir da die Verwendung von mehreren Shelves oder eine Patch-Queue aus der MQ-Extension ein.

Ein konkretes Beispiel für den "Testcode":
Es sollen von einem externen Gerät eingelesene Informationen auf einer neuen Seite in der Anwendung dargestellt werden. Um im normalen Betrieb auf diese Seite zu kommen muss man sich am Terminal mit einer Chipkarte identifizieren. Da mir das zu blöd ist, baue ich diese Überprüfung vorübergehend aus bzw. überspringe sie.

Wenn diese Änderung später im Programm verbleibt ist das nicht gut


Von dieser "Queues"-Erweiterung höre ich ständig, ich werde mir das wohl auch einmal ansehen müssen. Vielleicht wird das ja in die richtige Richtung gehen...

Zitat von Der schöne Günther:

Ein konkretes Beispiel für den "Testcode":
Es sollen von einem externen Gerät eingelesene Informationen auf einer neuen Seite in der Anwendung dargestellt werden. Um im normalen Betrieb auf diese Seite zu kommen muss man sich am Terminal mit einer Chipkarte identifizieren. Da mir das zu blöd ist, baue ich diese Überprüfung vorübergehend aus bzw. überspringe sie.

Wenn diese Änderung später im Programm verbleibt ist das nicht gut


Von dieser "Queues"-Erweiterung höre ich ständig, ich werde mir das wohl auch einmal ansehen müssen. Vielleicht wird das ja in die richtige Richtung gehen...

In einer perfekten Welt wäre das nichts anderes als ein Testumfeld (DUnit / DunitX) in dem Du die entsprechenden Identifizierungen gemockt hast - also durchaus Code der im Repo landet, allerdings nicht im Produktivcode, sondern im "Testcode".

Ich wollte noch einmal nachträglich sagen dass Uwes Vorschlag mit den Patch Queues genau war was ich wollte.

Es ist zwar manchmal etwas fummelig da man keine Änderungen in der Arbeitskopie haben darf bevor man den ersten Patch draufwirft.
Und ich brauchte durchaus etwas, um es überhaupt zu verstehen.

Aber im Endeffekt ist es ein toll steuerbarer Stapel "zwischen" dem letzten Commit und der Arbeitskopie. Profis können wahrscheinlich nur müde lächeln aber für mich war das Neuland.

Hallo,
Hm, also bei mir bleibt Testcode im SVN drin.
Per IFDEF lässt sich das leicht benutzen.


Heiko

Aber das bläht den Quelltext teilweise so unendlich auf

Ich gebe mal ein anderes Beispiel für welches ich die Patch Queues lieben gelernt habe:

Das Handbuch des Produkts enthält eine Vielzahl an Software-Screenshots. Das Handbuch sollte natürlich auch zur aktuellen Software-Version passen. Jetzt kann ich natürlich nicht für jedes neue Release, für jede Sprache von jeder Situation neue Screenshots machen.

Stattdessen habe ich mir einen Automatismus gebaut der die die einzelnen Abbildungen in jeder Sprache direkt als fertige Bilder auf die Platte legt. Dazu gehören natürlich auch "gefälschte" Oberflächen die suggerieren, eine Messung würde schon seit Stunden laufen.

Das alles ist ein einer Patch Queue. Neue Version? Patch-Queue einmal drauf werfen, Programm starten, fertig. Patches wieder runternehmen, normal weitermachen.