контроль версий: перенос исправления ошибки / улучшения кода в разработку функций

У меня есть вопрос о рабочем процессе, связанный с Mercurial (возможно, применимый к другим DVCS).

Репо настраивается с использованием стандартной / стабильной настройки по умолчанию.

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

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

Мне кажется, что использование патча имеет больше смысла. Вы можете сделать коммит специально для исправления ошибки и применить этот патч по своему усмотрению. Я имею в виду, что если ошибка не слишком неприятна, нет необходимости в срочности и прерывании вашего потока. Правильно?

Итак, как вы справитесь с этой ситуацией?

Спасибо


version-control workflow dvcs mercurial
person jbarreiros    schedule 13.01.2011    source источник
comment
Примечание: Wim предлагает жизнеспособную альтернативу сбору вишен, которую вы могли бы рассмотреть.   -  person VonC    schedule 13.01.2011

Ответы (2)


arrow_upward
6
arrow_downward

Вы можете вернуться к точке ветвления (версия B), исправить там ошибку (версия X), а затем объединить исправление в обе ветки (M1 и M2):

-----B--o----o---M1----o---> stable
     |          /
     |---------X   bugfix
     |          \
     \--o---o----M2----o-----> feature

Таким образом, вы можете получить исправление в каждой ветке с помощью обычных hg merge операций; никаких заплат, трансплантации или MQ не требуется.

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

person Wim Coenen    schedule 13.01.2011
comment
Ура, для парня, который понимает, где вы делаете изменение, так же важно, как и само изменение. - person Ry4an Brase; 13.01.2011
comment
Я могу понять, почему никто не хочет дублировать историю, но для простых исправлений трансплантация кажется самым простым методом, который, кажется, также сохраняет временную шкалу красивой и линейной, где слияние может как бы усложнить временную шкалу. Я просто ленивый? - person jbarreiros; 14.01.2011
comment
@jbarreiros: Это спорная тема. С одной стороны, есть люди, которым нравится сохранять свою историю красивой и линейной, как вы говорите, и они будут активно использовать такие вещи, как rebase, чтобы добиться этого. С другой стороны, есть люди, которые рекомендуют вносить все изменения в ветки функций. от стабильных исходных показателей. - person Wim Coenen; 14.01.2011
comment
Спасибо, Вим, за твой ответ. Ссылка (в вашем комментарии выше) и статьи, на которые она есть, также были очень информативными. - person jbarreiros; 14.01.2011
comment
@jbarreiros: действительно лучший выбор, чем мой ответ. - person VonC; 14.01.2011

arrow_upward
0
arrow_downward

Сделав небольшое исправление, вы можете использовать Hg Transplant Extension и сообщить о том же исправить на другой ветке.

Если это не подходит, другие возможности выбора вишни подробно описаны в вопросе SO "Mercurial изменения выбора вишни для фиксации ".

person VonC    schedule 13.01.2011
comment
Спасибо, VonC, расширение для трансплантации подойдет как нельзя лучше. Спасибо тоже за ссылку. - person jbarreiros; 13.01.2011
comment
Этого можно избежать, если улучшить рабочий процесс. Приведенное ниже решение Wim предпочтительнее, потому что вы не получите одно и то же изменение дважды в своем репо с разными хэш-идентификаторами. Одно и то же изменение в двух местах делает возможное слияние этих мест менее автоматическим. - person Ry4an Brase; 13.01.2011
comment
@ Ry4an: Согласен. Опять же, я слишком рассуждаю как пользователь Git;) - person VonC; 13.01.2011
comment
Хех, эй, все в порядке, и похоже, ему понравился твой ответ. Я просто подумал, что буду трубить о другом решении, чтобы замедлить ваше возможное вытеснение меня как лидера статистики для ртутного тега. ;) - person Ry4an Brase; 14.01.2011
comment
@ Ry4an: для меня ты всегда будешь лидером статистики Mercurial;) - person VonC; 14.01.2011