Скажем, есть две ветви, и последняя (HEAD) ревизия в ветви A равна 9, тогда как в ветви B. это 6 единиц.
Когда выполняется cd B; svn merge -r 5:8 ^/braches/A, svn попытается применить дельту между5 и 8 из ветви A поверх ветви B.
(Другими словами, наборы изменений 7 и 8 будут применены к B)
common
ancestor left right
(1)━━┱───(3)──(5)──(7)──(8)──(9) # branch A
┃ └┄┄┄┄┬┄┄┄┄┘
┃ ↓
┗━(2)━━(4)━━(6) # branch B
working
Если применяется дельтачисто, все хорошо.
Допустим, некоторые строки были изменены в наборе изменений 3, и те же строки источника были изменены по-разному в наборе изменений 4.
Если дельта (5 → 8) не касаетсяэти строки, все еще хорошо.
Если дельта (5 → 8) также изменила то, что сделали 3 и 4, изменения не могут быть объединены автоматически, и svn оставляет файл в состоянии конфликта:
- file --- файл с (рабочим, левым, правым) разделителем
- file.working --- состояние файла в ветви B @ 6
- file.merge-left -- состояние файла в ветви A @ 5
- file.merge-right --- состояние файла в ветви A @ 8
Если вы редактируете такой файл maв действительности, у вас есть несколько вариантов: продолжайте «работать» (ваша версия), сохраняйте «право» (их версия;другой версии ветки) или объедините изменения вручную.
«Слева» само по себе бесполезно, нет смысла оставлять «левую» (их старую версию) в файле.
ЭтоОднако полезно для инструментов.«left → right» - это набор изменений.
Когда вы видите, например:
<<<<<<< .working
foo = 13
||||||| .merge-left.r5
foo = "13"
=======
foo = "42"
>>>>>>> .merge-right.r8
Это говорит вам, что "13" было изменено на "42" в ветви A.
В ветви B было 13 (целое число, а не строка).
Скорее всего, вы выберете ручное слияние для изменения 13 на 42 и сохраните его целым числом.