Лучшие практические инструменты и методы для объединения производного снимка кода с обновленным исходным кодом?
Ситуация следующая: необходимо объединить изменения из исходной кодовой базы (от V1 до V2) в третью кодовую базу S1, которая получена / разветвлена из V1, чтобы создать новую кодовую базу S2.
У нас есть доступ к управлению версиями для журналов и ревизий между V1 и V2, а также источником V1, V2 и источником S1. Однако S1 не снабжен репозиторием управления версиями и историей: это невозможно трактовать как объединение ветви и развитой магистрали, учитывая, что промежуточные изменения для получения S из V1 не известны индивидуально.
Ситуация такова, что поэтому мы выполняем пошаговое трехстороннее объединение, чтобы получить S2, а изменения, полученные в S1, обновлены для работы на основе V2. (Наш развивающийся V2 естественно находится под контролем версий)
Я обнаружил, что WinMerge полезен для определения файлов, которые просто различаются / отсутствуют / добавляются между структурами каталогов, и p4merge как хороший инструмент трехстороннего слияния на уровне файлов.
Какие инструменты и методы вы предлагаете? Стоит отметить, что размеры кодовых баз велики, количество промежуточных ревизий между V1 и V2 велико, а размер изменений между V1 и S также велик.
5 ответов
Лично, хотя, возможно, и не так необычно, как вышеупомянутый детектор клонов, я бы начал с использования diff -u S1 V1 >/tmp/diffs.patch, который должен сказать вам, что было изменено в S1. Я подозреваю, что высокий процент различий можно объединить на V2 с patch -p0 </tmp/diffs.patch, Любое, чего он не может, будет исправлено настолько, насколько это возможно, и отклоненные изменения оставлены для ручного слияния.
Это должно обработать все "легкие" части за несколько минут. Возможно, вы захотите выполнить пробный запуск, а затем удалите несколько хитрых файлов из файла.patch, которые вы сделаете все слияния вручную с 3-сторонним слиянием.
Если изменения слишком обширные (масштабный рефакторинг или перемещение большого количества кода из файла в файл), то вам, возможно, придется использовать инструменты, подобные упомянутой Ира.
Я действительно рекомендую Beyond Compare. Он имеет чистый графический интерфейс, отличные алгоритмы сравнения, сравнение 3-х файлов, сравнение структуры каталогов и многое другое.
То, что вы хотите знать, это дельты между V2 и S1, и где они находятся.
Winmerge сообщает вам, что файлы абсолютно одинаковы или отсутствуют или отличаются. Если отличается, он не скажет вам, что у них общего, если что-то является основой для слияния.
Я бы использовал (наш) детектор клонов в V2 и S, чтобы узнать, что у них общего с гранулярностью языковых структур. Блоки кода, которые являются клонами из V2 в S в один и тот же файл, в некотором смысле "уже объединены"; там, где есть клоны V2 в другой файл в S, вероятно, произошло перемещение кода. При наличии параметризуемых различий детектор клонов (по крайней мере, наш) сможет сказать вам, что это за параметры ("правки"), и вы сможете решить, как их объединить. Там, где код сильно отличается, детектор клонов ничего не скажет, но вы можете получить этот список, вычтя файлы, которые, по словам детектора клонов, в основном являются клонами, из тех, которые, по словам Уинмерге, отличаются. Эти очень разные файлы, вероятно, будет трудно объединить.
Для файлов, которые в основном являются клонами друг друга, вы можете использовать наш Smart Differencer, чтобы сообщить вам, как файл V1 мог быть изменен для получения S; это обеспечит точную информацию об изменении зерна.
Вы должны использовать Git, чтобы сделать слияние. Оформить заказ S1, затем git merge v2.
Если S1 имеет много изменений между ним и V1, вы можете быть уверены, что переименования и т. Д. Вызовут наименьшее количество конфликтов. Кроме того, вы можете перебазировать (переиграть изменения) из диапазона от v1 до v2 поверх s1 или из диапазона от v1 до s1 поверх v2 - это зависит от того, чего вы хотите достичь. Это на самом деле не трехстороннее слияние.
как вы получаете историю v1..v2 и v1..s1 в git, зависит от вас.. Если не существует инструмента миграции, сценарий экспорта в каждой ревизии должен это делать. Затем просто зафиксируйте свои результаты поверх S1 как S2 в SCM, который вы используете.
Надеюсь это поможет,
Вы можете найти меня на канале #git irc, если вы хотите, чтобы моя помощь или еще куча других были ОЧЕНЬ хороши в слиянии.
Если V не находится в хорошем VCS, он может заплатить за импорт V в совершенно новый VCS для запуска. Затем создайте ветку в V1 и импортируйте каждую старую копию S1, которую вы можете найти из резервных копий, старых деревьев сборки, рабочих копий и т. Д. Постройте как можно больше истории из V1 в S1 в VCS. Если кто-то проделал какое-то радикальное переформатирование по пути, можно было бы нормализовать это, применив тот же инструмент к ревизиям ветки V2.
Затем используйте инструмент слияния и проложите свой путь через конфликты. Если их много (и, вероятно, будет), вам может потребоваться поэтапное слияние на этапах по истории V1..S1 и V1..S2, чтобы вы могли совершить промежуточную работу.