DVCS: Bunnyhopping noch notwendig?

[Der schöne Günther]

Anfängerfrage:

Szenario: Man arbeitet in einem Zweig und findet einen Bug. Bis dieser Bug gefixed ist kann man nicht weitermachen. Der Bug muss natürlich im Stamm korrigiert werden.

In SVN sah mein Vorgehen so aus:

1. Von aktuellem Zweig "/myFeature" zurück auf /trunk wechseln
2. Fehler beheben
3. Committen
4. Neuen Zweig von /trunk bilden: "/myFeature_2"
5. Zweig "/myFeature" in "/myFeature_2" mergen
6. Zweig "/myFeature" löschen
7. Auf "/myFeature_2" wechseln
8. weitermachen

Ist das in, sagen wir, Mercurial noch notwendig? In einem kleinen Test konnte ich lustig hin- und hermergen und alles schien reibungslos zu klappen. Meine Frage: Ist die Welt hier wirklich so unbeschwert oder steuere ich auf einen Abgrund zu, den ich erst in Monaten sehen werde?

[himitsu]

In SVN sah das eigentlich so aus. :stupid:

1. Von aktuellem Zweig "/myFeature" zurück auf /trunk wechseln ODER direkt ein ausgechecktes /trunk benutzen
2. Fehler beheben
3. committen
4. Revision des Bugfixes von Zweig "/trunc" in "/myFeature" mergen (eventuell /myFeature gleich mal komplett auf die aktuelle Revision des Trunc hochziehen, also alle neuen Revisionen)
5. Merge-Info committen (kann man auch später noch, aber nicht vergessen)
6. weitermachen

ODER

1. Fehler beheben (in /myFeature)
2. committen
3. Revision des Bugfixes von "/myFeature" in "/trunc" mergen
4. Merge-Info committen (kann man auch später noch, aber nicht vergessen)
5. weitermachen

Solange man die Merge-Infos committet hat, konnte SVN später recht gut bestimmen was bereits wo ist und hatte kaum Probleme beim hin- und hermergen.

Schwierig wurde es nur, wenn man Revisionen zwischen verschiedenen Brunches rumschob. (über mindestens 2 andere Branches hinweg)
Bei sowas sollte man besser immer über den Basispfad (z.B. Trunc) das Ganze verteilen ... also als Baum betrachtet die Ableitungen immer nur direkt die Äste entlang und keine Abkürungen kreuz und quer.

[Der schöne Günther]

Ich weiß nicht, das mit den Mergeinfos hat nie wirklich toll geklappt oder ist wohl falsch gemacht worden. Die Änderungen aus dem Trunk in den gleichen Zweig reinzuziehen war immer ein Patentrezept für riesige Mergekonflikte die eigentlich nicht hätten sein müssen. Zumindest habe ich das so in Erinnerung.

Ich habe es immer nur so gemacht, wie mir aufgetragen wurde- ohne Nachdenken. Ich bin ein guter Mitläufer.

[himitsu]

Mergeprobleme zwischen Trunc und Branch sind hier eigentlich immer nur aufgetreten, wenn man schon länger den Branch nicht aktualisiert hatte und sich an den zu mergenden Stellen zwischenzeitlich was geändert hatte, das noch nicht gemerget wurde.

Bei uns gab es anfangs Probleme, da die Mergeinfos einfach verworfen wurden (revert), weil man sich dachte "hier hab ich doch nichts geändert und das sieht nicht nach (absichtlichen) Änderungen von mir aus, also weg damit".

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1274994)

Ist das in, sagen wir, Mercurial noch notwendig? In einem kleinen Test konnte ich lustig hin- und hermergen und alles schien reibungslos zu klappen. Meine Frage: Ist die Welt hier wirklich so unbeschwert oder steuere ich auf einen Abgrund zu, den ich erst in Monaten sehen werde?

Das hängt weitestgehend von deiner Testabdeckung ab. Aber eigentlich ist das bei HG wirklich so. Du kannst dir das auch so vorstellen, daß myFeature und myFeature2 von jeweils anderen Entwicklern beigesteuert werden, die das ja auch in den trunk bzw. default mergen. Ob du jetzt allein an drei Branches arbeitest und mergest oder drei Entwickler in default ist faktisch dasselbe.

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1274994)

In einem kleinen Test konnte ich lustig hin- und hermergen und alles schien reibungslos zu klappen. Meine Frage: Ist die Welt hier wirklich so unbeschwert oder steuere ich auf einen Abgrund zu, den ich erst in Monaten sehen werde?

Kannst du machen, allerdings solltest du dich eher an ein Branching Model* halten.

(*) Da steht zwar git aber ich denke, das lässt sich mit Hg genauso benutzen.

[Der schöne Günther]

Wenn wir bei meinem Fall "Mich interessiert nur der eine Commit im default der den Bug gefixed hat" bleiben: Wo wäre denn jetzt der Unterschied zu einem "Graft"?


Anhand dieser liebevollen Skizze:

Code:

   ?   [Ich will den Fix aus default haben]
*  |
|  *
|  |
|  *
|  |
|  * myBranch
| /
|/
* Default

Nach dem Aufmachen meines Branches hat niemand mehr etwas an Default verändert. Ich fixe in Default diesen Bug. Wie bringe ich den Fix jetzt zurück? Per Merge oder Graft?

Spontan hätte ich doch gesagt dass ein "graften" generell die bessere Wahl ist da ich mir hier

1. gezielt einzelne Revisionen aussuchen kann
2. Es in der TortoiseHG-Werkbank auch nicht als Merge angezeigt wird. Die grafts kann man sich dazu noch einblenden, wenn man mag.

[Uwe Raabe]

Wenn in Default nur dieses eine zusätzliche ChangeSet vorhanden ist bleibt es Geschmacksache. Andernfalls wäre ein Graft wohl die bessere Wahl.

[Elvis]

Wenn du den Branch noch nicht irgendwohin gepusht hast (zm Beispiel für ein Code review), könnte man in Git einfach ein Rebase auf deinen "Default" machen damit dein Feature branch sauber auf dem neuen Changeset aufbaut (eventuelle Konflikte müssen natürlich behoben werden)
Sonst sähe das später so aus:


*\ merged fature
| * Fix in feature
|/|
X | Fix in default
| *
| |
| *
| |
| * myBranch
|/
* Default

Bei nur einem Fix in der Lebenszeit deines Feature branches mag das Okay sein. Aber irgendwann kriegt man da Augenkrebs. Da macht das dann IMO schon Sinn regelmäßig den Feature-Branch auf den aktuellen Hauptbranch zu stülpen (IOW: rebase)

Wenn ihr allerdings Code reviews á la Kiln nutzt, dann würde ich zwar vor dem ersten Review ein Rebase machen, aber von da an den Hauptbranch in den Featurebranch mergen.
Sieht dann nicht so toll aus, aber die Changeset ID bleibt erhalten, und somit auch die Reviews deiner Kollegen.

[Stevie]

Zitat:

Zitat von Elvis (Beitrag 1275904)

Wenn du den Branch noch nicht irgendwohin gepusht hast (zm Beispiel für ein Code review), könnte man in Git einfach ein Rebase auf deinen "Default" machen damit dein Feature branch sauber auf dem neuen Changeset aufbaut (eventuelle Konflikte müssen natürlich behoben werden)

... snip ...

Bei nur einem Fix in der Lebenszeit deines Feature branches mag das Okay sein. Aber irgendwann kriegt man da Augenkrebs. Da macht das dann IMO schon Sinn regelmäßig den Feature-Branch auf den aktuellen Hauptbranch zu stülpen (IOW: rebase)

Wenn ihr allerdings Code reviews á la Kiln nutzt, dann würde ich zwar vor dem ersten Review ein Rebase machen, aber von da an den Hauptbranch in den Featurebranch mergen.
Sieht dann nicht so toll aus, aber die Changeset ID bleibt erhalten, und somit auch die Reviews deiner Kollegen.

IIRC kannst du den 2. merge fast forwarden, so dass man in der History nur einen Merge commit hat. Von Branches rebasen halte ich persönlich nix, da holt man sich zu viel Ärger (außer der branch ist wirklich nur lokal vorhanden und die betroffenen Änderungen nicht remote). Außer halt wenn man nen remote pullt, das sollte man immer mit seinem lokalen rebasen, da man sonst unnötige Commits á la "merged remote/feature-x to feature-x" commits hat, die für Nüsse sind.

Bei dem gefragten Fall würd ich wohl zu nem cherry-pick (das ist wenn ich das richtig gelesen habe, das was in hg graft macht) tendieren.