Некоторая помощь в слиянии устаревшей ветки в Mercurial

Question

В настоящее время мы работаем над новой версией (версия 2.0) приложения.

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

Мы зафиксировали изменение, которое создало новую голову в нашем исходном дереве.

Вопрос в том, как лучше слить это? В идеале я хотел бы объединить его с набором изменений, который последовал за версией 1.0. Я не хочу сливать это в подсказку, потому что код, в котором была обнаружена ошибка, больше не существует.

Я понимаю, что, возможно, мне следовало создать отдельную ветку для "исправления ошибок v1.0".

Спасибо, Бен

Answer 1

При перемещении изменения в репозитории с помощью слияния речь идет о самом последнем общем предке того места, где у вас есть это изменение, и места, где вы хотите его получить.Если до внесения этого исправления ваше хранилище выглядело так:

[a]-[b]-[c]-[d]

с набором изменений с тегами 1.0, равным [b], то теперь у вас есть это:

[a]-[b]-[c]-[d]
      \
       -[e]

, где исправление находится в [e]. Если это так, то вам просто нужно сделать это:

hg update d
hg merge e
hg commit

Тогда у вас будет это:

[a]-[b]-[c]-[d]-[f]
      \         /
       -[e]-----

Если на другомРука до внесения изменений, ваш репо выглядел так:

[a]-[b]-[c]-[d]
      \
       -[e]-[f]

, где тряпка 1,0 указала на [f], тогда у вас теперь есть:

[a]-[b]-[c]-[d]
      \
       -[e]-[f]-[g]

с исправлениемв [g].Если вы хотите переместить набор изменений [g] в [d], не принося с собой [e] и [f], хорошего способа сделать это не существует.Не очень хороший способ, доступный вам (называемый cherrypicking ), заключается в использовании команд hg export и hg import.

Никакой рабочий процесс не требует выбора вишни, но для его избежания требуетсянемного предусмотрительности.Во втором случае вы бы избежали этого, сделав исправление не для серии 1.0 (как потомок [f]), а вместо этого как потомок самого последнего общего предка из двух мест, где вы хотите это изменение.Так как вы хотите это изменение как в [d], так и [f], вы ищете их последнего общего предка и видите его [b] и вносите изменения как дочерние для этого, используя следующие команды:

hg update b
..edit..
hg commit

оставляя вас с этим графиком:

[a]-[b]-[c]-[d]
      \
       \--[g]
        \
         -[e]-[f]

это исправление, [g] - новая голова, и вы можете объединить ее как в [d] (2.0), так и [f] (1.0) без какого-либо выбора вишнисовсем.Команды для этого были бы:

hg update d
hg merge g
hg commit
hg update f
hg merge g
hg commit

, и результирующий график будет выглядеть так:

[a]-[b]-[c]-[d]--[h]
      \         /
       \--[g]----
        \        \
         -[e]-[f]-[i]

, где [h] - ваш новый 2.0 с исправлением, а [i] - вашновая версия 1.0 с исправлением.

Резюме: вы всегда можете избежать ковыряния в вишне с помощью предвидения, но это не конец света, если вы не

Answer 2

Похоже, у вас есть это:

[a]-[b]-[v1]-[c]-[d]-[v2]
          \
           -[fix]

и вы хотите избавиться от лишней головы, не объединяя какие-либо изменения в [fix].

Option # 1

Следующие команды просто пометят ветвь как закрытую, она не будет считаться дополнительной головкой и будет скрыта от команд hg heads и hg branches:

hg update fix
hg commit --close-branch -m "closed branch" 

Опция # 2

Следующие команды будут «фиктивно сливать» лишнюю головку, отбрасывая любые изменения.

hg update v2
hg --config ui.merge=internal:fail merge
hg revert --all --rev .
hg commit -m "dummy merge"

флаг --config ui.merge=internal:fail предотвращает попытку инструмента слияния объединить любые конфликты, но не• не допускать появления файлов, добавленных в другой заголовок, поскольку не будет конфликтов слияния с вновь добавленным файлом.revert просто обновит все файлы до состояния первого родителя.Вы получите:

[a]-[b]-[v1]-[c]-[d]-[v2]-[merge]
          \                 /
           -[fix]-----------

, но содержимое [merge] будет таким же, как [v2].

Option # 3

Еще один способсделать фиктивное слияние:

hg update v2
hg debugsetparents v2 fix
hg commit -m "dummy merge"

Это устанавливает рабочий каталог на v2, но затем "подделывает" Mercurial, что оба v2 и fix являются родителями, и фиксирует это как слияние.