Управление ветками релизов в Mercurial

Question

Недавно я перешел с SVN на Mercurial. Теперь мне интересно, как реализовать намеченный рабочий процесс ветвления в Mercurial в соответствии с хорошей практикой, надеясь, что другие разработчики поймут, что происходит в репозитории.

Это рабочий процесс:

1. Обычно у меня есть ветка ствола / по умолчанию, где происходит работа над текущей серией выпусков. Допустим, это 1.x. В то же время я использую ветку 2.x для работы над следующим основным выпуском. Изменения в этой ветке могут быть радикальными, поэтому слияние с веткой trunk/default/1.x здесь не имеет смысла.
   • Через некоторое время работа над 2.x может быть закончена, и будет выпущена версия 2.0. Теперь я хочу, чтобы ветка 2.x была новой веткой по умолчанию / trunk, а текущая ветка default / trunk - веткой 1.x.
   • Повторяя этот процесс, может появиться новая ветка 3.x. Как и прежде, если выйдет 3.0, 3.x должна стать новой веткой по умолчанию, тогда как текущее значение по умолчанию должно стать веткой 2.x (снова).

Мой вопрос не в том, хорош ли этот рабочий процесс (я думаю, это не принципиально неправильно). У меня вопрос: можно ли считать способ, которым я это понимаю в Mercurial, хорошей практикой или есть ли лучшие возможности?

Итак, вот как я планирую управлять филиалами в Mercurial...

Начиная с репозитория с одной веткой, которая содержит код текущего выпуска серии 1.x:

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

Начните работать над выпуском 2.x:

$ 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"

Тем временем, поработайте в серии текущих выпусков (1.x):

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

Через некоторое время релиз 2.0 готов, ура! Сделайте ветку по умолчанию 1.x и 2.x по умолчанию:

$ 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"

Теперь создайте новую ветку 3.x и работайте в ней, также работайте по умолчанию. Опять же, через некоторое время 3.0 готов, и снова пришло время управлять именами веток:

$ 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"

Теперь репо может выглядеть так ("о" - головы):

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

Главное, в чем я не уверен, так это в том случае, если повторное использование имен веток и жонглирование с именем ветки по умолчанию является хорошей практикой.

Много текста на этот вопрос - извините, - но я хотел уточнить, что я делаю.

Answer 1

Вот что я бы сделал:

Делать default ваша "основная" ветка. Подсказка в этой ветке - версия вашего кода, "опубликованная в настоящее время". Критические исправления могут быть зафиксированы непосредственно в этой ветке и объединены в ветки разработки.

Чтобы начать работать над версией 2.0, сделайте 2.0-dev ветка. Внесите изменения для 2.0 в эту ветку и объедините критические исправления из основной строки (default) внутрь. Как только вы закончите с 2.0, объедините 2.0-dev в default и пометить результат как 2.0,

Поступая таким образом, вы не должны беспокоиться о манипулировании именами веток, и вы можете легко слить критические исправления с основной веткой в ​​ветки разработки.

Он также хорошо масштабируется, когда вы работаете над несколькими будущими версиями одновременно (скажем, 2.1 и 3.0). Вы можете периодически объединять изменения 2.1 в 3.0, чтобы поддерживать актуальность 3.0.

В итоге вы получите такой график:

$ 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

Я думаю, вы должны рассмотреть это: успешная модель git-ветвления.

Я не большой поклонник git, но эта модель очень полезна и для Mercurial.