Какой лучший способ закрыть ветку Mercurial?
Лучше сначала закрыть ветку, а затем объединить ее с веткой по умолчанию (например) или сначала объединить, а затем закрыть?
Например, в TortoiseHg в первом случае вы увидите линию от близкого узла к ветви по умолчанию. Во втором случае вы увидите строку от последнего коммита до ветви по умолчанию и дополнительную строку от последнего коммита до закрытого узла.
Я надеюсь, что я чист. Может быть, дело вкуса...
3 ответа
Нет никакой разницы между этими двумя методами, когда речь идет об именованных ветвях, по крайней мере, в любой недавней версии Mercurial. До-1.5(?) Все было иначе, но чисто в том, что hg heads а также hg branches будет включать эти "закрытые" ветви в свой вывод - они все еще могут, если вы укажете -c по команде.
Помните, что когда вы закрываете ветку (используя hg commit --close-branch или в Черепахе) вы фактически просто фиксируете новый набор изменений, в котором для изменения установлен флаг, указывающий, что ветвь X закрыта, - вы можете легко обновить ветку и открыть ее, выполнив другой коммит.
Однако при повторном открытии ветви "полоса", которую вы видите в "Черепахе", все еще будет существовать в ранее закрытом наборе изменений, и поэтому по одной только этой причине я лично выбрал бы политику закрытия, а затем слияния. Думаю, более визуально поучительно видеть, что вы сливались с чем-то, чем вы были довольны (и, следовательно, закрывали ветку до слияния).
С "анонимными" ветвями все немного отличается тем, что они не включены в hg branches вывод, когда они были объединены, и поэтому не требуют явного закрытия.
Это не дело вкуса, и есть разница. Короче, закройте ветку, затем объедините.
Дело в том, что для имен веток Mercurial это просто "метаданные" для каждого набора изменений. Это влияет на результаты некоторых команд, таких как hg branches пропускает закрытые или hg push по умолчанию запрещать добавление нового заголовка для каждой ветви. Но опять же - это фильтрация.
Внутри Mercurial рассматривает репозиторий как график изменений, а именно DAG. А топологические заголовки этого графа используются для реализации логики, например, при сравнении локальных и удаленных репозиториев во время hg pull, Большее количество топологических головок может (незначительно, но все же) влиять на производительность. Как закрытые ветви влияют на производительность Mercurial?, Также определенное количество из них может вызвать 400 Bad Request из Mercurial, запущенного на сервере IIS - https://bitbucket.org/site/master/issue/8263/http-400-bad-request-error-when-pulling.
Когда происходит одно слияние, а затем закрытие, ветвь закрывается - все в порядке, и человек по умолчанию не видит эту ветвь. Но у Mercurial есть еще одна топологическая голова. Смотрите ниже для визуального объяснения. Поэтому закройте сначала.
close then merge merge then close
---------------- ----------------
@ default, head @ default, head
| |
o merge <--> | x close branch, head
|\ | |
| x close branch <--> o | merge
| | |\|
o | dev on default o | dev on default
| | | |
| o dev on branch | o dev on branch
| | | |
| o open branch | o open branch
|/ |/
o default o default
Вы можете посмотреть здесь, как мы пришли к такому выводу.
Как недавно узнала моя компания, есть довольно веская причина, чтобы предпочесть слияние. Как уже говорилось в других ответах, при объединении-затем-закрытии вы получаете дополнительную "топологическую головку", тогда как при закрытии-затем-слиянии вы не оставляете эту дополнительную головку позади.
Оказывается, что эти дополнительные заголовки складываются и могут в конечном итоге вызвать проблемы в операциях синхронизации (когда Mercurial необходимо договориться о том, какие головки находятся на какой стороне, чтобы обнаружить наборы изменений, которые нужно сдвинуть или потянуть). По мере роста числа висячих топологических головок эти операции становятся все больше и больше, пока в конечном итоге они не начнут давать сбои. К счастью, вы можете довольно легко очистить их позже, но, вероятно, лучше всего сначала избежать этой проблемы.