Как управлять несколькими версиями продукта с Mercurial?

Question

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

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

В идеале, у нас должно быть базовое репо, которое является продуктом, а затем различные репо (или ветви) с дополнительными модулями, чтобы QA мог создавать основной продукт и основные + дополнения отдельно, в то время как разработчики, работающие над ModuleA, не влияют на разработчиков, работающих над BugfixB.Я пробовал это с несколькими подпунктами, но это привело к повреждению моих репозиториев.

Стоит ли смотреть на использование именованных веток?Или закладки?

Я ищу предложения по передовым методам использования возможностей Mercurial для упрощения этого процесса.

Спасибо!

Answer 1

Существует хороший учебник по ветвлению на http://nvie.com/git-model. Главное - иметь

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

Также есть ссылка на технические различия в ветках Mercurial на http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Answer 2

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

Answer 3

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

Я бы предположил, что каждое исправление ошибки имеет свою собственную ветку.Разработчики раскроют эту ветку, исправят ошибку и вернутся в ветку Feature.

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

Answer 4

Я думаю, что вопрос стирает две разные проблемы:

1. У вас есть модульный продукт
2. У вас есть отдельные циклы разработки для каждого модуля

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

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

Надеюсь, это поможет.

Answer 5

Я также новичок в Mercurial, но я думаю, что ваша проблема не является специфической для него. Вам нужно подумать о процессе выпуска кода и участвующих сторонах, и сопоставить эту модель с макетом ветви, который может ее поддержать. Mercurial хорош, потому что он может хорошо поддерживать разработчиков, позволяя им поддерживать собственные "ветки" разработки, не влияя на непрерывную сборку или другие последующие процессы (QA, установщики и т. Д.).

                            [Rel]

                               ^

                             [RC]
                               ^

            [QA]----[QA]------[QA]
              ^       ^        ^

[Dev] -------------------------------------------- -------------

       ^          ^          ^
      [Jen]      [Paul]    [Ken]

это возможная схема, в которой разработчики объединяются с Dev, а кто-то регулярно сливается с веткой [QA], а когда это хорошо выпекается, отправляется в [RC] и т. Д. Каждый релиз остается изолированным от других действий.

Удачи!