当从我的开发团队的主干执行“svn 合并”到分支时，我们偶尔会遇到合并冲突，从而产生具有后缀名称的文件：*.merge-right.r5004、*.merge-left.r4521 和 *.working。我搜索了整个 Subversions 的文档，但他们的解释并没有多大用处。我收集了以下内容：
我似乎无法弄清楚merge-left.r4521 是什么。如果答案是它只是分支文件的旧版本，那么为什么是 4521？
【问题讨论】：
r 之后的数字是修订号。扩展名为 .rXXX 的文件是该给定修订版中的文件。
标签： svn
假设有两个分支，分支A 中的最后一个（HEAD）修订版是9，而分支B 中是6。
当cd B; svn merge -r 5:8 ^/braches/A 运行时，svn 将尝试从A 分支B 顶部的分支8 应用5 和8 之间的增量。
（换句话说，更改集7 和8 将应用于B）
common
ancestor left right
(1)━━┱───(3)──(5)──(7)──(8)──(9) # branch A
┃ └┄┄┄┄┬┄┄┄┄┘
┃ ↓
┗━(2)━━(4)━━(6) # branch B
working
如果增量应用干净，一切都很好。
假设在变更集3 中修改了一些行，而在变更集4 中对相同的源代码行进行了不同的修改。
如果 delta (5→8) 没有触及这些线，一切都还好。
如果 delta (5→8) 也修改了 3 和 4 所做的，则无法自动合并更改，并且 svn 使文件处于冲突状态：
file --- 用 (working, left, right) 分隔的文件file.working --- 分支中的文件状态 B@6
file.merge-left --- 分支中的文件状态 A@5
file.merge-right --- 分支中的文件状态 A@8
如果您手动编辑此类文件，您有几个选择 --- 保留 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)。
【讨论】：
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
【讨论】：
这个问题与stackoverflow.com/questions/1673658/svnmerge-workflow类似，但这个问题更具体地说明了冲突文件的内容。
【讨论】：
似乎“左”文件是主干和分支中文件相同的最后一个版本（对于您的问题，但它通常在源和目标之间）。
如果您从未将主干中的更改合并到您的分支中，那么这将是执行分支（复制）时主干的版本。否则，它是合并并提交到此分支的最后一个主干版本。
左右是用于创建将应用于（作为补丁）到工作文件的差异。
【讨论】：
您执行了 3-side merge diring 冲突解决（当合并 2 个不同的文件时）。它这个操作使用了 3 个来源
r*** 扩展名刚刚添加到相同的文件名，以便合并 3 个文件
在成功合并并将冲突标记为已解决的临时文件后，如果我没记错的话，必须自动消失
【讨论】：