Различия между svn merge слева, справа и рабочими файлами после конфликтов

Ответ 1

Допустим, есть две ветки, и последняя (HEAD) ревизия в ветки A - это 9, в то время как это 6 в ветки B.

Когда запускается 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 --- файл с разделителями (working, left, right)
• file.working --- состояние файла в ветки [email protected]
• file.merge-left --- состояние файла в ветки [email protected]
• file.merge-right --- состояние файла в ветки [email protected]

Если вы редактируете такой файл вручную, у вас есть несколько вариантов: сохранить working (ваша версия), сохранить right (их версия; другая версия ветки) или объединить изменения вручную.

Left сам по себе бесполезен, нет смысла хранить left (их старую версию) в файле.

Это, однако, полезно для инструментов. left → right - набор изменений.

Например, когда вы видите:

<<<<<<< .working

    life_universe_and_everything = 13

||||||| .merge-left.r5

    life_universe_and_everything = "13"

=======

    life_universe_and_everything = "42"

>>>>>>> .merge-right.r8

В ветки A значение "13" (str) было изменено на "42".

Ветка B имеет 13 (int).

Возможно, вы хотите 42 (int), когда вы примиряете этот конфликт вручную.

Ответ 2

file.merge-left.r4521 - последнее изменение этого файла в левой ветки (т.е. происхождение) до, была создана правильная ветка (место назначения).

Другими словами, merge-left.r4521 это первая версия файла, который будет объединен

с merge-right.r5004 (последняя версия ветки назначения)

Например, скажем, вы хотите объединить ветки влево и вправо, как показано ниже:

Left   1   2   f.3   4   f.5   6    7    f.9    11 

Right                                  8    f.10    f.12   13


Right is created in 8 ( is a copy of 7 )

file 'f' has been modified in 3, 5, 9, 10, 12

The merge of file 'f' will occur between 7 and 13 because

7 is the latest version of file f in Left before Right was created

13 is the latest version of Right

Ответ 3

• 'file.py.merge-left.rxxx` показывает результат слияния с левой стороны конфликта.
• 'file.py.merge-right.ryyy` показывает результат слияния с правой стороны конфликта.
• 'file.py.working` показывает вашу неизменную рабочую копию.
• 'file.py` показывает, что SVN пытается объединить оба

Этот вопрос похож на fooobar.com/questions/207309/..., но этот вопрос более специфичен в отношении содержимого файлов конфликтов.

Ответ 4

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

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

Левый и правый - это то, что используется для создания diff, который будет применяться (как патч) к рабочему файлу.

Ответ 5

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

• "ваш" файл (из WC или исходного местоположения, в зависимости от параметров)
• "их" файл (файл с изменениями должен быть объединен)
• "базовый" файл (общий предок файлов 1-2)

r *** добавление добавлено к тому же имени файла, чтобы иметь 3 файла при слиянии

После успешного слияния и маркировки конфликта, как разрешенные временные файлы, должны исчезнуть автоматически, если моя память хорошо мне помогла