Лучшие практические инструменты и методы для объединения производного снимка кода с обновленным исходным кодом?

Question

Ситуация следующая: необходимо объединить изменения из исходной кодовой базы (от V1 до V2) в третью кодовую базу S1, которая получена / разветвлена ​​из V1, чтобы создать новую кодовую базу S2.

У нас есть доступ к управлению версиями для журналов и ревизий между V1 и V2, а также источником V1, V2 и источником S1.Однако S1 не снабжен хранилищем управления версиями и историей: это невозможно трактовать как объединение ветви и развитой магистрали, учитывая, что промежуточные изменения для получения S из V1 не известны по отдельности.

Ситуация такова, что поэтому мы выполняем пошаговое трехстороннее слияние, чтобы получить S2, а изменения, полученные в S1, обновлены для работы на основе V2.(Наш развивающийся V2, естественно, находится под контролем версий)

Я обнаружил, что WinMerge полезен при идентификации файлов, которые просто различаются / отсутствуют / добавляются между структурами каталогов, и p4merge как хороший инструмент трехстороннего слиянияна уровне файлов.

Какие инструменты и методы вы предлагаете?Стоит отметить, что размеры баз кода велики, количество промежуточных ревизий между V1 и V2 велико, а размер изменений между V1 и S также велик.

Answer 1

Лично, хотя, возможно, и не так необычно, как вышеупомянутый детектор клонов, я бы начал с использования diff -u S1 V1 >/tmp/diffs.patch, которое должно рассказать вам, что изменилось в S1. Я подозреваю, что высокий процент различий можно объединить на V2 с patch -p0 </tmp/diffs.patch. Любое, чего он не может, будет исправлено настолько, насколько это возможно, и отклоненные изменения оставлены для ручного слияния.

Это должно обработать все "легкие" части за несколько минут. Возможно, вы захотите выполнить пробный запуск, а затем удалите некоторые хитрые файлы из файла .patch, которые вы сделаете все слияния вручную с 3-сторонним слиянием.

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

Answer 2

Я действительно рекомендую Beyond Compare .Он имеет чистый графический интерфейс, отличные алгоритмы сравнения, сравнение трех файлов, сравнение структуры каталогов и многое другое.

Answer 3

Вы должны использовать Git для слияния. Оформить заказ S1, затем git merge v2.

Если S1 имеет много изменений между ним и V1, вы можете быть уверены, что переименования и т. Д. Вызовут наименьшее количество конфликтов. Кроме того, вы можете перебазировать (переиграть изменения) из диапазона от v1 до v2 поверх s1 или из диапазона от v1 до s1 поверх v2 - это зависит от того, чего вы хотите достичь. На самом деле это не трехстороннее слияние.

как вы добавляете историю v1..v2 и v1..s1 в git, зависит от вас .. Если инструмент миграции не существует, сценарий экспорта при каждой ревизии должен делать это. Затем просто зафиксируйте свои результаты поверх S1 как S2 в SCM, который вы используете.

Надеюсь, это поможет,

Вы можете найти меня на канале #git irc, если вам нужна моя помощь, или есть еще куча других, которые ОЧЕНЬ хороши в слиянии.

Answer 4

Если V не находится в хорошем VCS, он может заплатить за импорт V в совершенно новый VCS для запуска.Затем создайте ветку в V1 и импортируйте каждую старую копию S1, которую вы можете найти из резервных копий, старых деревьев сборки, рабочих копий и т. Д. Постройте как можно больше истории из V1 в S1 в VCS.Если кто-то проделал какое-то радикальное переформатирование, можно нормализовать его, применив тот же инструмент к ревизиям ветки V2.

Затем используйте инструмент слияния и разберитесь с конфликтами.Если их много (и, вероятно, будет), вы, возможно, захотите постепенно объединяться на этапах по истории V1..S1 и V1..S2, чтобы вы могли совершить промежуточную работу.

Answer 5

То, что вы хотите знать, - это дельты между V2 и S1, и где они находятся.

Winmerge сообщает вам, что файлы абсолютно одинаковы, или они отсутствуют или отличаются.Если отличается, он не скажет вам, что у них общего, если что-то является основой для слияния.

Я бы использовал (наш) Детектор клонов в V2 и S, чтобы выяснить, что у них общего с гранулярностью языковых структур.Блоки кода, которые являются клонами из V2 в S в один и тот же файл, в некотором смысле «уже объединены»;там, где есть клоны V2 в другой файл в S, вероятно, произошло перемещение кода.При наличии параметризуемых различий детектор клонов (по крайней мере, наш) сможет сказать вам, что это за параметры («правки»), и вы сможете решить, как их объединить.Там, где код сильно отличается, детектор клонов ничего не скажет, но вы можете получить этот список, вычтя файлы, которые, по словам детектора клонов, в основном являются клонами, из тех, которые, по словам Уинмерге, отличаются.Эти очень разные файлы, вероятно, будет трудно объединить.

Для файлов, которые в основном являются клонами друг друга, вы можете использовать наш Smart Differencer , чтобы сообщить вам, как файл V1 мог быть измененпроизводить S;это обеспечит точную информацию об изменении зерна.