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

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

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

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

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

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

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

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

Ответ 1

Вы можете использовать hg commit --close-branch, чтобы отметить ветвь как закрытую:

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

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

Что именно вы могли бы получить путем слияния?

Ответ 2

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

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

hg clone --rev good BadRepo FixedRepo

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

Мысли?

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

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

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

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

Ответ 3

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

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

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