На практике это то, что вы не должны делать часто, имена веток имеют тенденцию существовать долгое время(это не правило, лишь наблюдение).

8.6. Работа с несколькими поименованными ветками в хранилище.

Если у вас болльше чем 1 ветка с именем в хранилище, Mercurial будет помнить ветку вашей рабочей папки когда вы запустите такую команду, как hg update или hg pull -u. Это обновит рабочую папку с этой веткой. Обновить ветку с другим именем вы можете использовать опцию -C с командой hg update.

Посмотрим это на практике. Сперва вспомните, какая ветка сейчас «текущая» и какие ветки есть в нашем хранилище.

Мы можем использовать hg update назад и вперед между foo и bar ветками без нужды использовать опцию -C, потому-что это всего лишь перемещение по линейной истории наших изменений.

Если мы вернёмся к ветке foo и затем запустим hg update, мы останемся в foo, не перемещаясь к вершине bar.

$ hg update foo

0 files updated, 0 files merged, 1 files removed, 0 files unresolved $ hg update

0 files updated, 0 files merged, 0 files removed, 0 files unresolved

Внесение нового изменения в ветку foo создаст новую голову.

$ echo something > somefile

87

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

$ hg commit -A -m 'New file' adding somefile

8.7. Имена веток и слияние

Как вам вероятно уже известно, слияния в Mercurial не симметричны. Давайте представим, что у нашего репозитория две головы: 17 и 23. Тогда если я запущу hg update для 17, и затем hg merge с 23, Mercurial запишет 17 в качестве первого родителя слияния, и 23 в качестве второго. Тогда как если я запущу hg update для 23 и затем hg merge с 17, это запишет 23 первым родителем, а 17 — вторым.

Это влияет на то, какое имя ветки выберет Mercurial для результата вашего слияния. После слияния, mercurial сохраняет имя ветки первого родителя, когда вы фиксируете результат слияния. Если имя ветки вашего первого родителя foo, и вы слили с bar, после слияния веткой по-прежнему будет foo.

Это необычно, если хранилище хранит несколько голов, с одним именем ветки. Скажем, я работаю с веткой foo, как и вы. Мы сохраняем разные изменения; я забираю ваши изменения; у меня сейчас головы, обе претендующие быть в ветке foo. Результатом слияния будет одна голова в ветке foo, как вы могли надеяться.

Но если я работаю с веткой bar, то результатом слияния bar и foo будет ветка bar.

$ hg branch bar

$ hg merge foo

1 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit)

$ hg commit -m 'Merge' $ hg tip

changeset:

branch:

tag:

parent:

parent:

user:

date:

summary:

Более конкретный пример: если я работаю с веткой bleeding-edge и хочу внести в неё последние фиксы из ветки stable, то Mercurial выберет имя «правильной» ветки (bleeding-edge), когда вытащу и объединю изменения из ветки stable.

8.8. Именнованные ветки — это очень удобно.

Вам не стоит думать об именовании веток только когда несколько «устойчивых» веток находятся в одном хранилище. Это так же очень полезно даже для случая одна-ветка-на-хранилище.

88

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

В простом случае, если вы дадите имя каждой ветке, вы будете знать, какой ветке принадлежит фиксация. У вас будет больше контекста, когда вы попытаетесь проследить историю изменений.

Если вы работаете с общедоступным хранилищем, то вы можете задать pretxnchangegroup перехватчик, который будет блокировать все приходящие изменения с «неправильным» именем ветки. Это простой, но эффективный способ против случайного слияния изменений с «нестабильной» ветки в «стабильную». Так перехватчик может находится внутри общедоступного /.hgrc репозитория.

[hooks]

pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch

89