Структура Mercurial Repository для функций, стабильных версий и т.

Question

Я буду более конкретным с вопросом, если мне нужно, или превращу это в вики сообщества, если вы все думаете, что это подходит, но мой вопрос:

Моя команда разработчиков недавно начала использовать Mercurial (перешел из Subversion), и нам это нравится до сих пор. Мне интересно, есть ли ресурс «лучшие практики» об архитектуре хранилища. Что меня интересует, так это то, как лучше всего оставить стабильную копию репозитория (для доставки / экстренного исправления ошибок) при работе с функциями и новыми версиями. Я много читал об именованных ветках и клонированных репозиториях, и я надеюсь, что некоторые из вас, ребята, смогут пролить свет на то, что работает для вашей команды.

Что легче объединить после того, как функция была протестирована и готова к следующему выпуску? Есть ли серьезные недостатки у двух упомянутых мною методов? Существуют ли другие стратегии управления репо?

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

Позвольте мне перефразировать, чтобы затронуть некоторые основы, с которыми я все еще борюсь - Допустим, я заканчиваю 2.0.0 завтра ... Я хочу начать работу над 2.1.0, что мне делать ? Клонируйте мой репозиторий, назовите его «working / projects / widgets2.1» и продолжайте катиться вперед, чтобы мои «workin / projects / widgets2.0» были готовы к использованию в исправлении ошибок?

Далее, если клиент звонит и говорит, что есть ошибка, и машина виджета дрожит, и дым начинает развиваться, я могу открыть открытые виджеты 2.0, исправить ошибку, развернуть на сервере, затем зафиксировать / нажать? Должен ли я вернуться к widgets2.1 и вытащить / объединить это исправление ошибки?

Answer 1

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

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

Имея это в виду, я дам некоторые общие рекомендации для рабочего процесса между ветками, независимо от того, как онипредставлены в Mercurial (в виде отдельных репозиториев, именных веток и т. д.).Если вы хотите узнать больше о том, какую модель ветвления выбрать, я предлагаю вам прочитать Руководство Стива Лоша по ветвлению в Mercurial и мой пост в блоге о выборе модели ветвления в Mercurial .

Прежде всего, даже если веток нет вообще, вы все равно всегда можете вернуться к более ранней редакции кода, например, к версии 2.0, и исправить там ошибку.Это позволит легко пометить и выпустить новую версию (скажем, 2.0.1), единственное изменение - исправление ошибки.

Это можно сделать, просто обновив, исправив и зафиксировав:

$ hg update 2.0
hack hack hack
$ hg commit -m "Fix nasty bug"
$ hg tag 2.0.1

Вышеприведенное предполагает, что вы пометили ревизию 2.0, поэтому ее легко получить, иначе вам придется вместо этого указать хеш или идентификатор ревизии.

Это даст вам две головы, которые вы можете объединить.с помощью hg merge, возвращая исправление в версию для разработки.

Если у вас есть отдельный репозиторий для выпуска 2.0, вы вносите исправление в него, а затем помещаете его в репозиторий разработки, где затем объединяетесь.Основным принципом является тот, который описал Ry4an, вы вносите изменения там, где еще нет множества других изменений, которые вам не нужны.

Вот пример:

Где яВ работе у нас много репозиториев, представляющих разные отрасли.Большая часть разработки происходит в ветке "dev".Когда релиз приближается, мы клонируем этот репозиторий в новый, называемый скажем "release-2.4".В этой ветке / репозитории мы тестируем и исправляем ошибки в следующем выпуске.Дополнительные экспериментальные разработки, которые не будут готовы до следующего выпуска, могут происходить в "dev" параллельно.

Когда релиз протестирован и готов к выпуску, мы вытягиваем все из «release-2.4» в «prod», который содержит только выпущенные версии кода.Мы помечаем его номером версии и выпускаем для всего мира.Затем мы можем удалить ветку «release-2.4» и вытянуть все из «prod» в «dev».Это может потребовать слияния, но тогда мы внесем все изменения, сделанные в процессе выпуска, обратно в «dev» и сможем продолжить работу над следующим выпуском.

Если мы хотим исправить ошибку вне больших запланированных выпусковМы можем сделать это несколькими способами.Если исправление небольшое (пара коммитов) или не требует участия многих разработчиков, мы можем просто зафиксировать непосредственно «prod», пометить релиз и отправить его.После этого мы вытащим из «prod» в «dev», чтобы убедиться, что исправление есть и в следующем выпуске.

Если выпуск исправления ошибки больше и займет больше времени, мы можем вместо этого сделатьНовая ветка от "Prod", сделайте всю нашу работу над выпуском там, а затем перенесите изменения в "Prod".Когда он выходит в «prod», мы можем «вытянуть» из «prod» в «dev», чтобы получить изменения.Затем можно удалить специальную ветку релиза.

Answer 2

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

hg update 400
vi .... # fix bug
hg commit

Mercurial скажет «новая голова создана», что поначалу кажется тревожным, но вы сделали создание ревизии (фактически, анонимной ветви), которую можно hg pull добавить в любую ветку с ошибкой.

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

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

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

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

Answer 3

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

Ветви объектов существуют только в клоне репозитория пользователя, пока они не будут готовы для интеграции в основную линию разработки, после чего они будут объединены с активной веткой разработки.Если у вас есть кто-то в роли менеджера сборки, ветви функций могут быть перенесены в общий репозиторий без слияния, и менеджер может объединить их при необходимости.Если вы этого не сделаете, разработчики могут объединить их в своих клонированных репозиториях, а затем добавить уже объединенную ветвь.(Примечание: Hg будет по-прежнему отображать объединенную функциональную ветвь в общем репо)

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

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

отредактируйте, чтобы ответить на вновь добавленный вами конкретный вопрос

Допустим, завтра я закончу 2.0.0 ... Я хочу начать работу над 2.1.0, что мне делать?

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

Далее, если клиент звонит и говорит, что есть ошибка имашина виджетов дрожит, и дым начинает расти, открываю ли я виджеты 2.0, исправляю ли ошибку, развертываю на сервере, затем фиксирую / нажимаю?

Исправления для 2.0.0 будут сделаныпутем обновления до набора изменений 2.0.0 (т. е. тега), а затем создания новой именованной ветви (может называться version2.0.0 ).Эта ветвь никогда полностью не объединяется с веткой по умолчанию , которая теперь перешла к разработке 2.1.0, и эта ветка, вероятно, останется открытой бесконечно долго.Он будет содержать любые исправления, основанные на 2.0.0.

После того, как вы исправили ошибку 2.0.0, есть несколько способов переместить определенный набор параметров из 2.0.0 в ветку по умолчанию (2.1.0).Вы можете создать патч определенного набора изменений и применить его к default ветке, или вы можете выполнить слияние от version2.0.0 до default , если оно делаетсмысл.

Answer 4

Вот один хороший учебник по «структуре»:

http://hginit.com/05.html

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