В Mercurial, как объединить несвязанные репозитории, оставив только один корень?

Question

У меня есть 4 версии проекта. Версии 1-3 были «прототипами», которые первоначально не находились под контролем источника (они существуют как отдельные каталоги в файловой системе). Версия 4 находится под контролем источника с момента создания и теперь имеет долгую историю совершения.

Я хочу объединить их так, чтобы версии 1-3 становились индивидуальными наборами изменений, где каждый из них является потомком предыдущего. Корень версии 4 должен стать потомком версии 3 (и, конечно, не рушится история версии 4).

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

Что я сделал до сих пор, и попробовал:
1. I установки новых ¯hG репозиториев в каталоге версий прототипа
2. Я клонировать репозиторий версии 4
3. Я вытащил (с hg pull --force) несвязанные репозитории для версий 1-3 в клонированный репозиторий.

Это дает мне 4 несвязанных «корня» (изменения без предков) в одном репозитории. Когда я их совмещаю, я не хочу вспоминать эти 4 корня. hg rebase должен позволить мне перемещать изменения и уничтожать оригиналы, в отличие от hg merge.

Здесь я буду использовать 101 как ревизию для «версии 1» (которая представляет собой единый набор изменений без родителя) и 102 в качестве пересмотра для «версии 2».

Попытка 1: Пробовать hg rebase -b 102 -d 101, но получить ответ nothing to rebase. Предположительно это происходит потому, что у них нет общего предка (я чувствую, что это непоследовательно ... -b 102 будет включать в себя все предки кроме общего предка, который не будет ничего в этом случае.)

Попытка 2: Я стараюсь hg rebase -s 102 -d 101 , Это приводит к конфликтам слияния. Я делаю hg revert --all --rev 102 и hg resolve -m, чтобы указать, что я предпочитаю «версию 2» во всех конфликтах (хотя мне интересно, действительно ли это правильный способ предпочесть один родитель над другим при наличии добавлений/удалений?). Но когда я фиксирую, у меня нет линейной истории --- ревизия 102 все еще там!

Answer 1

Если я делаю hg rebase --continue в качестве окончательной команды (вместо hg commit), тогда она отлично работает.

Я не читал последнюю часть документации:
http://www.selenic.com/mercurial/hg.1.html#rebase

Answer 2

Как я знаю, что лучше использовать --tool "internal:other" на перебазирования вместо возврата к пересмотру.

Answer 3

Альтернативой rebase, который работал для меня, является использование расширения hg convert и --splicemap.

Хотя convert предназначен для фактической миграции из других систем управления версиями (например, SVN), он также может «конвертировать» с hg на hg.

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

Я не уверен, что это обязательно «лучшее» решение, чем перебаза. Это может быть более нишевым подходом для нечетных случаев (?). Одним из очевидных недостатков является то, что для больших репозиториев процедура преобразования может занять довольно много времени.

Splicemap documentation.