Mercurial: комплектация обязательна для включения в релиз

Question

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

Для уточнения, предполагая, что A, B, C, D и E являются коммитами, которые я уже сделал в своем хранилище, каждый из них связан с исправлением ошибки, например:

A <- B <- C <- D <- E <- working dir

Мне нужно иметь возможность, например, выбрать, какие из исправлений будут включены в версию выпуска (это зависит от времени, выделенного для развертывания, а также от результатов тестирования). Так, например, я мог бы получить отчет о том, что релиз должен содержать только исправления ошибок A, C и D.

Можно ли создать версию выпуска, содержащую только коммиты A, C и D (Помните, что каждый коммит самодостаточен и не зависит от других коммитов на самом деле)?

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

Answer 1

Это не обычный режим работы Mercurial (или git). Репозиторий может содержать набор изменений только в том случае, если он также содержит всех его предков. Таким образом, вы не можете получить D в репо, не имея там A, B и C.

Так вот:

Что вы должны были сделать

Контролируйте происхождение ваших ревизий. Не делайте C родителем D только потому, что вы исправили D после C. Прежде чем исправить ошибку hg update в предыдущем выпуске.

Представьте, что A - это релиз, а B, C и D - исправления ошибок. Если вы делаете такой цикл:

foreach bug you have:
    hg update A
    ... fix bug ...
    hg commit 
    hg merge  # merges with the "other" head

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

---[A]----[B2]--[C2]--[D2]----
    |    /     /     /
    +-[B]     /     /
    |        /     /
    +-----[C]     /
    |            /
    +---------[D]

и теперь, если вы хотите создать релиз только с, скажем, B и D, вы можете сделать:

hg update B
hg merge D

и это создает новую голову, у которой есть A + B + D, но нет C.

Tl; Dr: сделайте так, чтобы родитель изменения был как можно раньше в истории, а не то, что в данный момент является tip .

Что вы можете сделать сейчас

Это идеал, но, к счастью, это не так уж важно. Вы никогда не сможете передать точно D без C (поскольку хэш C является частью вычисления хэша D), но вы можете достаточно легко перенести работу, находящуюся в D, в новую голову. Вот несколько способов, каждый из которых будет работать:

• экспорт ртутного столба / импорт ртутного столба
• рт.ст. трансплантат
• ртутный трансплантат (новый в 2.0)
• hg rebase (возможно, только если вы еще не нажали)

Любой из них позволит вам перенести этот патч / дельту, находящуюся в D, на другой - у него будет другой хэш-идентификатор, и когда однажды вы объедините D в режиме реального времени (используя слияние), вы получите дублирующую работу в двух разных наборы изменений, но слияние решит все это.

Answer 2

Если бы это было мое дерево, и оно нигде не было передано, я бы (при условии, что пустая очередь исправлений и MQ включены):

hg qimport -g -r B:       # import revisions B and later into mq as "git" style patches
hg qpop -a                # unapply them all
hg qpush --move C         # Apply changes in C (--move rearranges the order)
hg qpush --move D         # Apply changes in D
hg qfin -a                # Convert C & D back to changesets 
hg push <release server>  # Push them out to the release branch

Тогда вы можете hg qpush -a; hg qfin -a, чтобы получить B &E обратно в наборы изменений.

Окончательный результат:

---A---C---D---B---E

Преимущества:

• Никто не должен знать, что вы не делали вещи в этом порядке, чтобы начать с (злая улыбка)
• Вы можете изменить любой из наборов изменений при этом

---

В качестве альтернативы, с прививкой в ​​2.0:

hg update -r A            # Goto rev A (no need to do anything special for A)
hg graft C                # Graft C on to a new anonymous branch
hg graft D                # Graft D

Это даст вам

---A---B---C---D---E
    \
     --C'--D'  <-You are here

hg push -r D' должен просто толкнуть новую, отобранную вишню, голову.

Затем вы можете hg merge, чтобы снова получить одну голову с включенными B и E.

Преимущества:

• Неразрушающий, так что истинная история сохраняется, и нет шансов на потерю, если вы испортите
• hg помечает новые наборы изменений с помощью хэша оригинальной версии,полностью отслеживаемый
• Возможно, немного проще.

Answer 3

Хотя это как-то странный способ и политика выпуска, вы можете сделать это в другой форме.Вы должны манипулировать двумя основными объектами: наборами изменений и ветвями

Версия 1

Вы используете две ветви (по умолчанию + fe "release 1.0").Ветвь по умолчанию - это основная линия вашей работы - все ревизии зафиксированы в этой ветке.Во время выпуска вы сначала разветвляете набор изменений, необходимый для выпуска, в (новую) ветвь, трансплантат или остаток трансплантата , необходимый в наборах изменений релиза от значения по умолчанию к этой ветви, глава выпуска 1.0 будет подготовлена ​​к выпускутаким образом.

Следующий выпуск будет отличаться только новым именем ветви

Версия 2

Используется одна ветвь, добавлено расширение MQ.Варианты:

• все ревизии являются MQ-патчами и только необходимы для релиза применяются к репо
• ревизии являются ревизиями, только нежелательны для релиза преобразовано в mq-pathes, позже qfinish'ed и возвращено в репо