На какую голову поставить перед выполнением слияния?

Question

Есть ли предпочтительная голова при слиянии?

Что я имею в виду: у меня есть, скажем, старая версия 1000. Между тем я выполнил 234 коммита и у меня 1234 оборотов.Теперь мне нужно вернуться к версии 1000, чтобы реализовать исправление для клиента.Я фиксирую исправление, даю релиз клиенту и получаю коммит 1235.

Это всего лишь крошечное изменение: влияет только на один файл.

На данный момент у меня две головы: 1235(чей родитель - 1000) и 1234. Их общий (grand-grand -...- parent) - 1000.

Если я выдаю hg merge, за которым следует hg status, я получаю гигантский списокизменений.

Однако если я сначала сделаю hg update -C 1234, а затем hg merge и hg status, то я увижу только свое уникальное изменение (если не ошибаюсь в том, что только что произошло).

По сути, выполнение этого:

hg update -C 1234
hg merge  # (merging 1234 and 1235, my two only heads)
hg status

дает статус, отличный от этого:

hg update -C 1235
hg merge  # (merging 1234 and 1235, my two only heads)
hg status

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

Это нормальное поведение и, если да, есть ли одна головка, которая "предпочитает"поверх другого?

В результате обе операции приводят к одному и тому же состоянию репозитория / исходного кода в конце?

Answer 1

Да, оба они приводят к одному и тому же конечному состоянию. Слияния почти на 100% симметричны в Mercurial. Единственная несимметричная часть - это именованные ветви :

hg update branch-a
hg merge branch-b
hg commit

создаст набор изменений на branch-a. Обновление до branch-b сначала создаст его на branch-b. Вы можете изменить ветвь коммита слияния, введя hg branch перед фиксацией, поэтому имя ветви по умолчанию больше похоже на предложение.

Однако, в вашем случае, я бы определенно обновился до версии 1234, а затем включил исправление в эту версию. Я думаю об этом так: у вас есть основная линия разработки - именно здесь вы работаете над новыми функциями для следующего выпуска.

Когда вы вносите исправление в старую версию, вы обновляете ее обратно, вносите исправление и выпускаете исправление для вашего клиента. Затем вы создали еще одну (крошечную) ветку для исправления. Вопрос о том, куда обновляться до слияния, теперь таков:

• я хочу продолжить по ветке с исправлениями ошибок? Если это так, то оставайтесь на исправлении и объединяйте в нем основную ветвь.

• я хочу продолжить по основной ветке? Если это так, тогда обновитесь до основной ветки и добавьте в нее ветку исправлений.

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

Подумайте о названных ветках, которые я упомянул выше - там вы бы сделали

hg update 1.x
# fix bug
hg commit
hg tag 1.3

, чтобы вернуться к серии программного обеспечения 1.x, исправить ошибку и выпустить версию с исправлением 1.3. Когда вы закончите, вы захотите объединиться с веткой default. Так как имя ветви наследуется от первого родителя в слиянии, его наиболее гладко сначала обновить до значения по умолчанию:

hg update default
hg merge 1.x
hg commit

Это рекомендуемый способ сделать это в Mercurial.