Mercurial Workflow советы

Question

Я получил небольшой совет по использованию Mercurial.

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

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

Answer 1

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

Представьте, что вы поддерживаете три релиза Head, Head-1 и Head-2. В Head-1 вы реализовали серьезное изменение рефакторинга. Теперь вы реализуете три новые функции в Head, которые хотите включить в Head-1 и Head-2. Поскольку Head и Head-1 имеют одинаковый большой рефакторинг, объединение новых функций в Head-1 не будет таким уж сложным. Однако для слияния новых функций в Head-2 вам, возможно, придется разрешить одни и те же конфликты слияния всех трех функций, чтобы обойти основной рефакторинг.

Правда в том, что вы, вероятно, уже делаете это - вы просто не знаете об этом, потому что CVS также не помогает вам с объединениями в другом направлении. Более новые системы контроля версий, такие как Mercurial и Git, могут значительно облегчить слияние в прямом направлении.

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

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

Answer 2

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

Думайте о слиянии ветвей как о слиянии рек: все, что было в одной, находится и в другой, после того, как вы слились. Вот почему, если вы хотите реализовать функцию, которая должна заканчиваться в нескольких ветвях, предложенный способ заключается в том, что вы реализуете ее в одной из них, а затем объединяете в другие. Очень важно понимать, что все , которое было в исходной ветке, попадет в целевую ветвь, а не только в реализованную вами функцию.

Так что разумно иметь ветки прошлой версии, чтобы сформировать матрешку . Например, у вас есть три долгоживущие ветви: 1.x, 2.x и default. Все функции в 1.x также присутствуют в 2.x и default, все функции в 2.x также присутствуют в default. (Здесь default является этапом для вашей следующей основной версии; вы создаете новую ветку 3.x, когда вы выпускаете v3.0.)

Итак, если вы хотите создать новую функцию в 1.x, вы реализуете ее там и затем делаете два слияния: 1.x в 2.x, затем 2.x в default (это вперед портирование ). Если вы попытаетесь сделать это наоборот, в default (это обратное портирование ), вы не сможете объединить default в 1.x или 2.x, потому что default имеет много других вещей, которые не должны появляться в старой версии. Трудно идти против течения, поэтому вам придется перенести необходимые изменения обратно в 1.x и 2.x, что, скорее всего, не будет применяться чисто, и вы будете в основном делать то, что Mercurial может делать вручную. сделать для вас.

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