Verwalten Release Niederlassungen in Mercurial

Question

Vor kurzem wechselte ich von SVN zu Mercurial. Jetzt frage ich mich, wie mein beabsichtigten Verzweigung Arbeitsablauf in Mercurial zu realisieren nach guter Praxis, in der Hoffnung andere Entwickler zu verstehen, was im Repository geschieht.

Dies ist der Arbeitsablauf:

1. In der Regel habe ich einen Stamm / default Zweig, in dem die Arbeit an der aktuellen Release-Serie passiert. Lassen Sie uns sagen, dass ist 1.x Zur gleichen Zeit verwende ich einen Zweig 2.x auf der nächsten Hauptversion zu arbeiten. Änderungen in dieser Branche können radikal sein, so mit dem Stamm / default / 1.x Zweig Verschmelzung macht hier keinen Sinn.
   • Nach einer Weile Arbeit auf 2.x werden beendet und die Version 2.0 wird freigegeben. Jetzt möchte ich die 2.x-Zweig der neue Standard / trunk Zweig und die aktuelle default / Stamm sein die 1.x Zweig zu sein.
   • Wiederholen dieses Prozesses kann es kommen, einen neuen 3.x-Zweig. Wie zuvor, wenn 3.0 veröffentlicht wird, 3.x den neuen Standardzweig werden soll, während der dann aktuelle Standard der 2.x Zweig werden soll (wieder).

Meine Frage ist nicht , ob dieser Arbeitsablauf ist gut (ich denke, es ist nicht grundsätzlich falsch). Meine Fragen sind, ob die Art, wie ich dies in Mercurial realisieren kann als gute Praxis zu sehen ist oder wenn es bessere Möglichkeiten.

Also hier ist, wie ich plane, verwalten Niederlassungen in Mercurial ...

Ausgehend von einem Repository mit einem einzigen Zweig, der den Code des aktuellen Release-Serie 1.x gilt:

$ hg init
$ echo "hello world" > file1.txt
$ hg ci -A -m "Initial commit of 1.x code"

Starten Sie auf Release 2.x arbeiten:

$ hg branch 2.x
$ hg ci -m "Create new branch for 2.x development"
$ echo "Big new feature for 2.x" > file2.txt
$ hg ci -A -m "Add big new feature"

Unterdessen haben einige Arbeit in der aktuellen Release-Serie (1.x):

$ hg up default
$ echo "Minor adjustments specific for 1.x" > file3.txt
$ hg ci -A -m "Minor adjustments"

Nach einiger Zeit Release 2.0 fertig ist, yippee! Machen Sie default Zweig 1.x und 2.x default :

$ hg up default
$ hg branch 1.x
$ hg ci -m "Make default branch to 1.x branch"
$ hg up 2.x
$ hg ci --close-branch -m "Close branch 2.x"
$ hg branch --force default
$ hg ci -m "Make former 2.x branch to new default"

Jetzt eine Niederlassung erstellen 3.x und Arbeit drin, auch auf arbeiten default . Wieder nach 3,0 einiger Zeit bereit ist, und es ist Zeit wieder Zweig Namen zu verwalten:

$ hg up default
$ hg branch --force 2.x # (reuse previously closed 2.x branch name)
$ hg ci -m "Make default branch to 2.x branch"
$ hg up 3.x
$ hg ci --close-branch -m "Close branch 3.x"
$ hg branch --force default
$ hg ci -m "Make former 3.x branch to new default"

Die Repo nun wie folgt aussehen ( 'o' sind die Köpfe):

o Branch default (3.x)
|
| o Branch 2.x
 \|
  | o Branch 1.x
   \|
    |
    .

Der wichtigste Punkt bin ich nicht sicher über, wenn Wiederverwendung Zweignamen und Jonglieren mit dem Zweignamen default ist eine gute Praxis.

Eine Menge Text für diese Frage - sorry -. Aber ich wollte darüber klar sein, was ich tue

Answer 1

Hier ist, was ich tun würde:

Machen Sie default Ihre "Hauptstrecke" Zweig. Die Spitze dieser Branche ist die Version des Codes „die derzeit für die Öffentlichkeit freigegeben“. Kritische Fehlerbehebungen können direkt auf diesen Zweig und fusionierte in Entwicklungszweige gebunden werden.

So starten Sie auf Version 2.0 arbeiten, einen 2.0-dev Zweig machen. Commit Changes für 2,0 bis diese Verzweigung und Zusammenführen kritische Fehlerbehebung von der Hauptstrecke (default) hinein. Sobald Sie mit 2.0 fertig sind, 2.0-dev in default verschmelzen und das Ergebnis als 2.0 markiert.

Dinge zu tun, auf diese Weise bedeutet, Sie müssen sich keine Gedanken über Jonglierzweignamen Sorge, und Sie können ganz leicht kritische Fehlerbehebungen an der Hauptstrecke in Entwicklungszweige zusammenführen.

Es ist auch gut skaliert, wenn Sie auf mehr zukünftigen Versionen auf einmal arbeiten ist (zB 2.1 und 3.0). Sie können die 2.1 Änderungen in 3.0 periodisch fusionieren 3.0 aktuell zu halten.

Sie werden mit einem Diagramm am Ende wie folgt:

$ hg glog -l 1000
@       changeset:  25:efc0096f47c0  tip
|       summary:    Added tag 3.0 for changeset d1a7fc3d7d77
|
o       changeset:  24:d1a7fc3d7d77  3.0
|\      summary:    Merge in the redesign changes.
| |
| o     changeset:  23:b5b69d24c8f7 3.0-dev
| |     summary:    Finish 3.0 redesign.
| |
| o     changeset:  22:4c2f98fac54b 3.0-dev
|/|     summary:    Merge in the latest changes to 2.1/mainline.
| |
o |     changeset:  21:37df04521032
| |     summary:    Added tag 2.1 for changeset 39ecc520fc0a
| |
o |     changeset:  20:39ecc520fc0a  2.1
|\ \    summary:    2.1 development is done.
| | |
| o |   changeset:  19:208f3f9236af 2.1-dev
| | |   summary:    Finish the 2.1 work.
| | |
| | o   changeset:  18:4a024009a9d6 3.0-dev
| | |   summary:    More redesign work.
| | |
| | o   changeset:  17:00c416888c25 3.0-dev
| |/|   summary:    Merge in changes from the 2.1 branch to keep the redesign current.
| | |
| o |   changeset:  16:a57e781a0db1 2.1-dev
| | |   summary:    More 2.1 work.
| | |
| | o   changeset:  15:ddeb65402a61 3.0-dev
| | |   summary:    More redesign work.
| | |
+---o   changeset:  14:90f5d7a8af9a 3.0-dev
| | |   summary:    Merge in the fire fixes.
| | |
| o |   changeset:  13:78a949b67bb9 2.1-dev
|/| |   summary:    Merge in the fire fixes.
| | |
o | |   changeset:  12:6dfe9d856202
| | |   summary:    Oh no everything is on fire, fix it in the mainline.
| | |
| o |   changeset:  11:86767671dcdb 2.1-dev
| | |   summary:    Smaller changes for 2.1.
| | |
| | o   changeset:  10:25dec81d2546 3.0-dev
| | |   summary:    Work more on the redesign.
| | |
+---o   changeset:  9:42c7d689fb24 3.0-dev
| |     summary:    Start working on a complete redesign.
| |
| o     changeset:  8:3da99186ca7d 2.1-dev
|/      summary:    Start working on 2.1.
|
o       changeset:  7:9ba79361827d
|       summary:    Added tag 2.0 for changeset 755ed5c5e291
|
o       changeset:  6:755ed5c5e291  2.0
|\      summary:    Merge in the dev branch for 2.0.
| |
| o     changeset:  5:44a833fcc838 2.0-dev
| |     summary:    Finish work on 2.0.
| |
| o     changeset:  4:d7ba6aae1651 2.0-dev
|/|     summary:    Merge in the critical fix.
| |
o |     changeset:  3:968049f1b33a
| |     summary:    Fix a critical bug on the main branch.
| |
| o     changeset:  2:917869609b25 2.0-dev
| |     summary:    More work on the new version.
| |
| o     changeset:  1:f95798b9cb2e 2.0-dev
|/      summary:    Start working on version 2.0.
|
o       changeset:  0:8a3fb044d3f4
        summary:    Initial commit.

Answer 2

Ich denke, Sie sollten dies berücksichtigen: ein erfolgreiches git Verzweigung Modell .

Ich bin nicht der große Fan von git, aber dieses Modell ist besonders nützlich für Mercurial zu.