Mercurial workflow для ~ 15 разработчиков. Должны ли мы использовать названные ветки?

Моя команда только начинает с Mercurial и центрального репозитория. У нас есть Хадсон, создающий кончик "дефолтной" ветки, которая в основном является нашей основной линией. У нас была политика регистрации с нашим старым VCS, что проверка кода, тестирование и т.д. Должны быть выполнены до регистрации на главной линии.

Итак, скажем, вы работаете над функцией X. Вы работаете над некоторыми вещами, основываясь на "умолчанию", а затем фиксируете частичную функцию в качестве контрольной точки. Локально ваш "по умолчанию" теперь сломан - вы еще не поделились им ни с кем, но если бы вы сделали толчок, теперь у вас сломанный код в mainline.

Даже если вы ждете, пока не будете все разобраны, кажется, что есть ситуации (например, работа над двумя вещами одновременно), где вам нужно будет внести некоторые изменения, но не все.

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

Мы начали использовать именованные ветки - но чем больше я читаю, тем больше я думаю, что мы неправильно используем названные ветки.

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

Ответ 1

Во-первых, я очень рекомендую Руководство по ветвлению в Mercurial

Далее вы можете нажать только текущую ветку: Nudge - Gentler версия Push

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

Другие вопросы SO, относящиеся к названным веткам:

Ответ 2

Вы можете рассмотреть как минимум два репозитория. В репозитории "mainline" есть ваш проверенный и проверенный код. Код отправляется только в этот репозиторий после того, как Хадсон протестировал его и после того, как все ваши отзывы были завершены. Репозиторий "тестирования" будет клоном основной линии. Это хранилище, которое Hudson контролирует, так что всякий раз, когда набор изменений переносится в тестовый репозиторий, тесты Hudson. Вероятно, вы можете настроить шаг сборки Hudson, который подталкивает изменения из тестового репозитория к вашей магистрали, если тесты пройдут.

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

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

Отказ от ответственности: я использовал Hg только для тривиальных проектов и тривиальным образом.

Ответ 3

То, что мы делаем в моей компании, - это использовать именованную ветвь, чтобы отличать стабильную версию (на которой мы только фиксируем исправления ошибок) и следующую версию, на которой происходит эта разработка, и мы регулярно исправляем исправления от стабильного до стандартного (с hg merge stable в ветке по умолчанию).

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

Отказ от ответственности: мы не используем Хадсон.

Ответ 4

Это вопрос мышления. Распределенные VCS не требуют, чтобы вы сохраняли один центральный репозиторий.

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

Как вы управляете получением изменений в mainline, тогда это широко открытый вопрос с множеством возможных ответов. Вот два с головы:

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

Ответ 5

Вы также можете использовать расширение Bookmarks вместо названных ветвей.

Если вы знакомы с git, закладки ведут себя как git -branches вместо меркуриальных ветвей.