Versionskontrolle: Verschieben eines Bug Fix/Code Verbesserung um Feature-Entwicklung

Ich habe eine Workflow-Frage im Zusammenhang mit Mercurial (möglicherweise für andere DVCS).Versionskontrolle: Verschieben eines Bug Fix/Code Verbesserung um Feature-Entwicklung

Der Repo wird mit dem typischen Standard/Stable-Setup eingerichtet.

Sie müssen ein neues Feature erstellen und erwarten, dass es einige Zeit dauert (Monat +). Wenn Sie an dieser Funktion arbeiten, stoßen Sie auf einen Fehler, von dem Sie denken, dass er früher als später behoben und auf die Produktion angewendet werden sollte. Oder vielleicht bemerken Sie etwas Code, der besser dokumentiert werden könnte.

Meine Annahme ist, dass Sie den Fix in Standard setzen und dann auf stabil umschalten und die Korrektur erneut machen (per Hand oder durch Anwenden eines Patches). Ist das korrekt oder solltest du sofort auf stable umsteigen, die Änderung dort vornehmen und dann stabil in den Default einbinden?

Die Verwendung eines Patches scheint für mich mehr Sinn zu machen. Sie können einen Commit speziell für die Fehlerbehebung durchführen und diesen Patch nach Belieben anwenden. Ich meine, wenn der Fehler nicht zu unangenehm ist, gibt es keine Notwendigkeit für Dringlichkeit und brechen Sie Ihren Fluss. Recht?

Also, wie gehst du mit dieser Situation um?

Dank

Quelle

2011-01-13 jbarreiros

Hinweis: Wim schlägt eine brauchbare Alternative zum Rosinenpicken vor, die Sie in Betracht ziehen könnten. – VonC

Sie können an der Verzweigungsstelle (B Revision) zurück, reparieren es den Bug (Revision X) und dann das Update in beiden Zweigen verschmelzen (M1 und M2):

-----B--o----o---M1----o---> stable 
    |  /
    |---------X bugfix 
    |   \ 
    \--o---o----M2----o-----> feature

Auf diese Weise können Sie Holen Sie sich Ihren Fehler in jedem Zweig mit normalen hg merge Operationen; kein Patchen, Umpflanzen oder MQ'ing erforderlich.

Die gleiche Idee einen Schritt weiter gehen: Sie könnten stattdessen auf die Revision zurückgehen, die den Fehler in erster Linie eingeführt hat. Wenn Sie dies als Basis für den Fix verwenden, können Sie Ihren Fix in jedem Zweig zusammenführen, der den Fehler enthält.

Quelle

2011-01-13 20:05:06

Huzzah, für den Typ, der versteht, "wo" du die Veränderung machst ist genauso wichtig wie die Veränderung selbst. –

+1 für die Vermeidung von Geschichtsumschreibung. – VonC

Ich kann verstehen, warum man Geschichte nicht duplizieren möchte, aber für einfache Korrekturen scheint "Transplantation" die einfachste Methode zu sein, die auch die Zeitachse nett und linear zu halten scheint, wo eine Zusammenführung die Zeitleiste irgendwie komplizieren kann. Bin ich nur faul? – jbarreiros

Sobald Sie Ihre kleine fix gemacht haben, begehen, können Sie die Hg Transplant Extension und berichten, dass gleiche Update auf einem anderen Zweig verwenden können.

Wenn dies nicht angemessen ist, sind in der SO-Frage "Mercurial cherry picking changes for commit" weitere Rosinenpickmöglichkeiten aufgeführt.

Quelle

2011-01-13 17:45:08 VonC

Vielen Dank VonC, die Transplantationserweiterung wird einfach schön machen. Danke für den Link auch. – jbarreiros

Man kann dies mit einem besseren Workflow vermeiden. Die untenstehende Lösung von Wim ist vorzuziehen, da Sie in Ihrem Repo nicht zweimal die gleiche Änderung mit unterschiedlichen Hash-IDs erhalten. Die gleiche Änderung an zwei Orten macht das eventuelle Zusammenführen dieser Orte weniger automatisch. –

@ Ry4an: Ich stimme zu. Noch einmal, ich argumentiere zu sehr wie ein Git Benutzer;) – VonC

Versionskontrolle: Verschieben eines Bug Fix/Code Verbesserung um Feature-Entwicklung

Antwort

Verwandte Themen