Есть два способа сделать это, и они расходятся не во время выпуска, а когда вы исправляете ошибку, в зависимости от того, какого родителя вы предоставляете наборы изменений исправления.«Хороший» способ использует только push, pull и merge.Менее хороший способ (это не совсем плохо, но он, безусловно, неоптимальный ) называется сбор вишни , и у него есть недостатки.Сложность в том, что если вы собираетесь перемещать исправления ошибок в RELEASE с помощью слияния, не перемещая все из TRUNK в RELEASE, вы должны решить, прежде чем вносить это изменение.
Вот действительно полный ответ на аналогичный вопрос, который объясняет, что происходит: Некоторая помощь по слиянию устаревшей ветки в Mercurial
Однако ключевая концепция заключается в том, что вы можете объединить набор измененийв любую ветку, которую вы хотите , но она приносит с собой все наборы изменений своего предка.Итак, вы хотите, чтобы ваша ошибка была исправлена, чтобы иметь минимальное происхождение Это означает исправление ошибки не в новом наборе изменений в TRUNK, который оказывается самой последней добавленной вами функцией, а вместо этого, во-первых, hg update в отношении набора изменений, который уже существует как в вашем TRUNK, так и в вашем RELEASE, и есть два большихкандидаты на это.Либо:
- набор изменений, где RELEASE и TRUNK расходятся
, либо
- набор изменений, где была введена ошибка
Я предпочитаю позже.Если ошибка была внесена в changeset 666, то каждый клон, ветвь и сборка, которые имеют changeset 666, захотят ваше исправление.Поэтому, исправляя это, просто сделайте:
hg update 666
.. fix the bug ..
hg commit -m "fixed bug 55" # creats changeset 999 which a new head
Тогда вы можете сделать это:
hg update TRUNK
hg merge 999
, и вы будете знать, что вы тянете только одну ревизию.Позже, когда вы будете готовы к выпуску, вы можете сделать:
hg update RELEASE
hg merge 999
и вы снова получите только одну нужную вам ревизию.
Преимущество этого режима работы по сравнению с cherrypicking (использование экспорта / импорта или трансплантации) заключается в том, что ваше исправление существует только один раз в вашем репо.Если у вас есть 99 различных веток поставщиков для разных привередливых клиентов, и вы хотите посмотреть, есть ли у них исправление для ошибки 55, вы можете просто сделать:
hg log -r 'descendants(999) and heads(FUSSYCUSTOMERBRANCHNAME)'
и если нет результатов, то этот клиент неимеют 999 и, следовательно, не имеют исправления для ошибки 55 в наборе изменений 666. Когда вы повторяете ту же работу с несколькими наборами изменений (что является результатом экспорта / импорта и трансплантации), это сложнее проверить.