Какая голова накладывается на перед слиянием?

Question

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

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

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

На данный момент у меня есть две голов: 1235 (чей родитель 1000) и 1234. Их общие (гран-гранд -...- родительский) 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, а затем объединить исправление в эту ревизию. Они, как я думаю, это то, что у вас есть основная линия развития - здесь вы работаете над новыми функциями для следующего выпуска.

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

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

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

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

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

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

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

hg update default 
hg merge 1.x 
hg commit 

Это recommended way сделать это в Mercurial.