Хранение экспериментальной истории из общего хранилища в Mercurial

Question

Я довольно плохо знаком с Mercurial, но одно из преимуществ, которые я вижу при использовании Mercurial, заключается в том, что при написании функции вы можете более свободно экспериментировать, проверять изменения, делиться ими и т. Д., Сохраняя при этом «чистоту». репо для готовой функции.

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

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

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

Мой вопрос таков: я делаю это более сложным, чем нужно? Есть ли лучший рабочий процесс, который я могу использовать, чтобы облегчить свои проблемы? Не слишком ли ожидать чистой истории, когда все (мелкие) функции включены в один набор изменений?

Или, может быть, весь мой вопрос можно сформулировать так:

Есть ли эквивалент для этого в Mercurial? Свертывание истории git-репозитория

Answer 1

Хотя я думаю, что вам следует пересмотреть использование веток в Mercurial (согласно моему комментарию к вашему сообщению), использование именованных веток не очень помогает в вашей заботе о сохранении бесполезной или ненужной истории - оно просто немного их упорядочивает.

Я бы порекомендовал комбинацию этих инструментов:

1. ртутные очереди
2. гистедит (не распространяется с Hg)
3. функция полосы ревизий mq

, чтобы переделать грязную историю перед тем, как перейти к благословенному или главному репо.Проще всего было бы использовать strip для окончательного удаления любых изменений без детей.После этого вы можете использовать mq или histedit для объединения, перемещения или изменения существующих коммитов.Histedit даже позволит вам повторить комментарий, связанный с набором изменений.

Некоторые подводные камни:

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

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

Answer 2

Именованные ветви - самое простое решение.Каждый экспериментальный подход имеет свою собственную ветвь. Это сохраняет историю экспериментов.

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

Следующее решение - и, вероятно, то, что вы действительно ищете - это расширение mq, которое может «сжать» ряд патчей в один коммит.Я считаю mq «продвинутым» и «подверженным случайным выстрелам себе в ногу».Я также не хочу раздавить мои коммиты - мне нравится, когда моя история версий представлена ​​для справки.