Есть ли обратная сторона этого рабочего процесса Mercurial: именованная ветка "мертвая" голова?

Question

Мне нравится гибкость именованных ветвей, но у меня есть некоторые опасения по поводу увеличения количества голов.

Даже когда ветвь закрыта, она все равно обнаруживается в головах.У меня есть идея, как очистить вывод от «hgheads». Мой вопрос к гуру: «Чего мне не хватает?»

Прежде всего вы можете спросить, почему я могу хотеть полностью спрятать голову?именованной ветви?По разным причинам:

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

edit: Оказывается, увеличение количества голов является симптомом более старой версии Mercurial, которую я использовал.Закрытие ветви скрывает ее верхнюю часть на более новых версиях Mercurial.

Моя идея состоит в том, чтобы иметь "мертвую" ветвь головок, в которую будут объединены все эти закрытые головки ветвей.
Мёртвая голова должна быть родоначальницей ревизии 0 и служить единственной цели - связать ненужные головы, которые сейчас не нужны.

У мертвой головы есть только другие дочерние головы, которые никогда не сливаются обратно в ветку по умолчанию.

Answer 1

Вы можете использовать hg commit --close-branch для пометки ветви как закрытой:

http://www.selenic.com/mercurial/hg.1.html#commit

Закрытые ветви не будут отображаться в hg branches или hg heads по умолчанию (только еслиуказана опция -c / --closed), поэтому я не уверен, как вы видите "беспорядок"?

Что именно вы получите, объединяя вещи?

Answer 2

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

Предположим, у вас много закрытых головок ветвей и только одна незамкнутая активная ветвь.Предположим далее, что в какой-то более поздний момент вы делаете плохой коммит (rev bad) поверх незакрытой головы (rev good).Прежде чем вы нажмете, вы хотите клонировать свой репозиторий, отбросив этот плохой коммит.Обычно это просто сделать -

hg clone --rev good BadRepo FixedRepo

К сожалению, это не тянет закрытые ветви веток, так как они не являются хорошими предками rev.Все те ветви, которые были закрыты, не будут закрыты в клонированном хранилище.Я проверял это с Mercurial 2.3.1.

Мысли?

ps Расширение hgflow закрывает функцию и освобождает ветви перед слиянием.Это позволяет избежать проблемы с закрытыми головами.

Что касается клона, являющегося уродливым подходом, он работал довольно хорошо и легко для меня.Клон заменяет хранилище плохим коммитом.Клон является локальным усилием.Это плохое хранилище просто отбрасывается.Я обычно понимаю, что вскоре после этого сделал плохой коммит.

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

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

Answer 3

Я чувствую, что замутил воду тем, почему я мог бы сделать частичное клонирование.Я перефразирую свою озабоченность по поводу закрывающих головок более тщательно.

Для любого частичного клона от репозитория X к репозиторию Y, если в репозитории X есть ветвь B с закрывающей головкой, и эта ветвь включена в клонпо чисто топологическим причинам, тогда ветвь B не будет закрыта в хранилище Y. Кроме того, если шаблон слияния должен вообще оставлять закрывающие головки, то число закрывающих головок имеет время разработки порядка.

Это касаетсяменя, так что я закрываю свои ветви, прежде чем слиться.Я использую hgflow (http://nvie.com/posts/a-successful-git-branching-model). Возможный частичный клон будет состоять в том, чтобы клонировать ветвь разработки и следовать ей с извлечением основной ветки (например, если вы хотите устранить тупики). Если ветви функций и выпусков были закрыты после их окончательногосливается, тогда эти ветви будут вновь открыты в клоне.