Свн слиться из сундука

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

  • Как это могло произойти? Это как-то связано с mergeinfo?
  • Каковы побочные эффекты не проверки в этих файлах в моей ветке, учитывая, что нет никаких изменений...
  • Будут ли проблемы, когда я попытаюсь слиться с туловищем?
Источник

2 ответа

Решение

Одна из вещей, которые вы можете увидеть, - это отчет об обновлении файла во время слияния, хотя это не так. Это может быть связано с обновлением svn:mergeinfo свойство в этом файле или каталоге.

Как правило, только корневой каталог проекта должен иметь svn:mergeinfo собственности на него, потому что вы почти всегда должны сливаться из корня проекта. Однако некоторые разработчики имеют привычку объединять отдельные файлы и каталоги, потому что они знают, что они были изменены. Когда разработчик делает это, Subversion начинает отслеживать слияние этих файлов и каталогов с их собственным индивидуальным svn:mergeinfo имущество.

Теперь, когда вы делаете слияние, все эти svn:mergeinfo Свойства должны быть обновлены, даже если сам файл не изменился. В конце концов, Subversion STILL должен отслеживать, что вы сделали конкретное слияние, даже если это не повлияло на этот файл, чтобы иметь возможность отследить, что было и не было слито.

Если svn:mergeinfo это проблема, не возвращайте файл. В противном случае Subversion просто повторяет бесполезное слияние снова и снова. Вы можете попробовать удалить svn:mergeinfo и от ствола и от ветви для этого конкретного файла, но будьте осторожны, чтобы не потерять отслеживание того, что было объединено.

Слияние в Subversion не так ясно, как должно быть. Subversion распознает два разных типа слияния:

  • Регулярное слияние, когда вы объединяете работу из транка в конкретную ветку.
  • Реинтеграция сливается там, где работа над веткой сливается обратно в ствол.

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

Почему?: Все изменения в этой ветви были объединены в транк, создав новую ревизию транка. Если вы выполняете слияние новой магистрали Subversion с ветвью, Subversion увидит эту новую ревизию, созданную слиянием, и попытается объединить все изменения, содержащиеся в новой ревизии, обратно в ветку.

Чтобы справиться с этим, используйте --record-only опция слияния, чтобы объединить эту новую ревизию из транка обратно в ветку. Теперь, когда вы сливаетесь из магистрали обратно в ветку, эта новая ревизия не будет рассматриваться для слияния:

$ svn co $REPO/trunk
$ cd trunk
$ svn merge --reintegrate $REPO/branch/1.2    #Two-way Reintegrating branch 1.2 to trunk
$ svn commit -m"Reintegrate 1.2"
commit revision 12345

Слияние создало ревизию 12345. Это должна быть запись только в ответвлении, чтобы мы могли повторно использовать ответвление:

$ svn co $REPO/branch/1.2
$ cd 1.2
$ svn merge -c 12345 --record-only $REPO/trunk
$ svn commit -m"Mark Reintegrate Merge as completed"

резюмировать

  • Как это могло произойти? Это как-то связано с mergeinfo?

Да, это так. Вы можете удалить svn:mergeinfo информация из этого файла из магистрали и ветви. Тем не менее, вы должны быть осторожны. Или вы можете игнорировать это сейчас, когда вы знаете, что все в порядке.

  • Каковы побочные эффекты не проверки в этих файлах в моей ветке, учитывая, что нет никаких изменений...

Subversion просто попытается снова выполнить слияние в следующий раз, когда вы выполняете слияние с каждым слиянием, которое занимает все больше и больше времени, поскольку каждый раз необходимо объединять больше ревизий.

  • Будут ли проблемы, когда я попытаюсь слиться с туловищем?

Когда вы сливаетесь из ветви в ствол, вы должны использовать --reintegrate параметр, чтобы предотвратить повторное включение ветви обратно в транк. Слияние при реинтеграции использует только двустороннее слияние. Это в основном делает ствол соответствовать ветви.

Как только это будет сделано, вы должны быть осторожны с новыми слияниями из магистрали в ветку.

Источник

Дэвид был прав в большинстве (не во всех) аспектах неприятностей, связанных с "Merge-Hell". Но я хочу пролить дополнительный свет на некоторые конкретные детали

  1. Когда вы выполняете обычный diff, вы можете сравнивать только контент (и некоторые различия могут пропустить некоторые изменения из-за настроек - например, изменения стиля EOL, если это изменение игнорируется в / в основном GUI/ diff-viewers)
  2. Каждый объект в репозитории может содержать не только контент, но и служить контейнером для данных, не относящихся к контенту (читайте про svn: properties, svn:mergeinfo - только один из наиболее очевидных примеров, но каждый файл может содержать больше пользовательских свойств), которые также объединяются (заменено, обновлено) в процессе слияния. svn diff в измененной рабочей копии после слияния (перед фиксацией) будут показаны все изменения в WC, svn diff между двумя узлами (mergeset и source of merge) тоже покажет все эти детали - попробуйте
  3. Когда вы выполняете объединение поддеревьев (объединение только части вложенного дерева), а затем выполняете полное объединение (т. Е. Вы разветвляете /A/B/C-файл, по некоторым причинам объединяете только C-файл и позже повторяете для /A/B/C-file, последнее слияние удалить mergeinfo, содержащуюся в C-файле)
Источник
Другие вопросы по тегам