Mercurial: слияние кросс-версий / массовый сбор вишен

Ситуация

У нас есть 2 версии (1.0 и 2.0) проекта, обе активно поддерживаются. По сути, это один и тот же проект (в том, что касается изменений), но основанный на разных базовых версиях (base1.0 и base2.0). Все, что изменилось в 1.0, также должно быть перенесено в 2.0. То же самое касается base1.0 и base2.0.

В mercurial у нас есть 4 ветки: base1.0, 1.0, base2.0 и 2.0. Что-то вроде этого:

                         __2.0
             __base2.0__/
            /
__base1.0__/___1.0____________

Теперь каждый раз, когда мы что-то меняем в базовой версии, мы вносим изменения в base1.0 и выполняем слияние hg с base2.0. Здесь нет проблем.

Теперь, когда мы делаем то же самое для 1.0 и хотим объединить их в 2.0, нам также нужно повторно объединить всю ветку base1.0. в 2.0, хотя это уже было сделано при создании base2.0 из base1.0.

Вопрос

Каков наиболее эффективный способ решить эту проблему? У меня было несколько подходов:

  1. Объединить: как объяснялось выше, это вызывает много накладных расходов и необходимость повторного выполнения уже выполненной работы.
  2. graft, также известный как «выбор вишни»: выберите все изменения, которые мы делаем в 1.0, и перенесите их в 2.0 с помощью hg graft. Хотя в некоторых случаях он работает, он создает дубликаты наборов изменений, потому что портирует их 1:1. Я бы хотел, чтобы была одна фиксация, содержащая все обновления, сделанные на 1.0, перенесенные на 2.0.
  3. Экспорт различий: я также пытался экспортировать различия между исходным 1.0 и самым последним 1.0, а затем импортировать его в 2.0. Но это патч, а патчи - зло. И не очень удобный в обращении.

Есть идеи? Будучи относительно новым для всей концепции SCM, я просто хотел услышать, что другие делают в таких сценариях. Спасибо.


person Hemisphera    schedule 29.05.2014    source источник
comment
Можете ли вы уточнить, что происходит во время слияния? Mercurial не должен переделывать то, что было объединено ранее.   -  person Lasse V. Karlsen    schedule 29.05.2014
comment
Я думаю, проблема в том, что 2.0 не имеет прямого отношения к 1.0, поэтому при слиянии он пытается снова объединить base1.0 в 2.0, имея base1.0 в качестве единственного общего предка. Конфликты, которые были решены при создании base2.0, должны быть решены снова.   -  person Hemisphera    schedule 29.05.2014
comment
Вы смотрели на этот способ организации филиалов? andy.mehalick.com/2011/12/24/an- введение в hgflow   -  person Lasse V. Karlsen    schedule 29.05.2014
comment
Я не думаю, что понимаю, почему это решит мою проблему. Мне все равно пришлось бы иметь 2 «главных» ветки, потому что есть две разные версии, которые продолжают существовать бок о бок в течение довольно долгого времени, не так ли?   -  person Hemisphera    schedule 29.05.2014
comment
Да, но я думаю, что одна из ваших проблем в том, что вы пытаетесь объединить всю ветку 1.0 с 2.0. Вместо этого вы должны попытаться создать отдельные ветки для новых функций, укоренить их в своей истории, где между версиями 1.0 и 2.0 не так много различий, а затем объединить их в версии 1.0 и 2.0. Но трудно сказать, потому что я до сих пор не знаю, с какими проблемами слияния вы сталкиваетесь, или почему Mercurial ведет себя так. Если вы столкнулись с проблемой слияния, дальнейшее слияние одних и тех же ветвей не должно вызывать эти проблемы снова.   -  person Lasse V. Karlsen    schedule 29.05.2014
comment
Предположим, я получил некоторые конфликты, объединив изменения в ‹FileA› из изменений base1.0 в base2.0. Если позже я объединим некоторые изменения в ‹FileB› с 1.0 на 2.0, снова возникнет тот же конфликт в ‹FileA›, даже если я не изменил ‹FileA› на ветка 1.0, только ‹FileB› Это основная проблема, с которой я столкнулся.   -  person Hemisphera    schedule 30.05.2014


Ответы (1)


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

Что мне действительно было нужно, так это выбрать все мои изменения с 1.0 на 2.0. hg graft делает это довольно хорошо, но создает дополнительную фиксацию на 2.0 для каждого привитого набора изменений и портит мой график.

Итак, что я сделал, так это создал клон моего репозитория, а затем пересадил все наборы изменений с помощью hg graft из 1.0 в 2.0. Затем я экспортировал различия между пре-прививкой и пост-прививкой и импортировал эту разницу в качестве исправления в исходное репо.

По сути кумулятивный "взнос" без какой-либо информации о том, откуда он взялся. Это было именно то, что мне было нужно, и сработало для меня в этом случае.

person Hemisphera    schedule 19.06.2014
comment
Ps: после этого я совершил логическое слияние, используя hg debugsetparent, чтобы отслеживать, до какой степени в 1.0 изменения включены в 2.0. - person Hemisphera; 19.06.2014