Answers:
如“ Tree Conflict”设计文档的较旧版本（2009）中所述：
XFAIL因添加版本控制文件合并而发生冲突
该测试进行合并，将没有历史记录的文件添加到现有版本文件中。
这应该是'local obstruction, incoming add upon merge'品种文件上的树冲突。固定了r35341中的期望。
（顺便说一下，这在ClearCase中也被称为“邪恶的双胞胎”）：
在两个不同的分支中两次创建了一个文件（此处两次“添加”），为两个不同的元素创建了两个不同的历史，但是名称相同。
理论上的解决方案是在目标分支“ B2”中手动合并这些文件（使用外部diff工具）。
如果您仍然在源科的工作，理想的情况是，除去从源分支文件B1从，合并回B2至B1以使在该文件中看到B1（然后你会在相同的元素工作）。
如果由于合并仅发生在B1到之间而无法进行合并B2，则每次合并都必须进行手动合并B1->B2。
alias mtc='stat | awk "BEGIN { FS=\" \" } /^.{6}C/ { print \$NF }"' 然后可以将其用作resolve命令的参数，如下所示： svn resolve --accept working $(mtc)
svn resolve --accept working path/index.html
如果要进行的更改是怎么办？我无法运行svn resolve-完全接受
svn resolve --accept base
我设法设法完全遵循我的用户619330的建议。情况是：（1）：在最初的分支branch1上工作时添加了一些文件；（2）我创建了一个新分支branch2进行进一步开发，将其从主干分支出来，然后合并了对branch1的更改。（3）一位同事将我的mod从branch1复制到了自己的分支，并添加了更多mod，然后合并回行李箱；（4）现在，我想将最新的更改从主干合并到我当前的工作分支branch2中。这是svn 1.6.17。
合并的树与新文件存在冲突，因此我希望从主干文件所在的新版本中删除新文件，因此，从干净的branch2副本中，我对冲突文件进行了svn删除，并提交了这些branch2更改（从而创建了一个临时文件）版本的branch2，而没有相关文件），然后从主干进行合并。我这样做是因为我希望历史记录与主干版本相匹配，以便以后在尝试合并回主干时不会出现更多问题。合并进行得很好，我得到了文件的主干版本，svn st显示一切正常，然后在尝试提交更改时遇到了更多的树冲突，包括我之前所做的删除和合并中的添加。svn解决了冲突，转而使用我的工作副本（现在具有文件的主干版本），并提交了它。
好吧，不。Branch2另一个副本的更新导致文件的旧版本（主干合并）。因此，现在我有branch2的两个不同的工作副本，据称已更新为同一版本，并具有文件的两个不同版本，并且都坚持认为它们是最新的！签出branch2的干净副本会导致文件的旧版本（预迁移）。我手动将它们更新为主干版本并提交更改，返回到我的第一个工作副本（本来是我最初提交主干更改的），尝试对其进行更新，现在在所涉及的文件上出现校验和错误。吹掉有问题的目录，通过更新获取新版本，最后我有了干线更改后应该是正确的branch2版本。我希望。警告开发人员。