我不知道svn团队什么时候决定对我们造成树冲突，但它完全破坏了svn的合并功能。
我有一个分支，我想将主干中的最新更改合并到分支中。我已经完成了一次这样的合并，但由于树冲突，这个合并失败了。这是命令：
$ svn --force merge -r 3185:3192 svn://chamar2/rx-services/SAMS .
svn: Attempt to add tree conflict that already exists
我第一次尝试此合并（没有--force）时，它只创建了树冲突并且没有合并任何内容。现在它只是报告上面的消息。
如果我在分支工作副本上执行svn status，它会显示所有尚未合并到主干的更改的文件。当然，我的分支的目的是在尚未进入主干的地方进行这些更改。
当他们这样做时，他们在想什么？
我没有找到任何关于导致树冲突的原因的可用信息以及我现在如何继续工作，因为svn创造了这些东西。
有没有办法告诉svn忘记树冲突，只是按照惯例进行合并？
我正在使用1.6客户端和较旧的svn服务器（可能是1.3.1）。
答案 0 :(得分：13)
问题原来是我选择了父/目录作为合并的源而不是父/ trunk /目录。这是用户错误，但树冲突消息令人困惑。如果svn刚刚完成合并，我会立即看到问题。
树冲突引入了一些需要习惯的新消息语义。
感谢指向Tortoise上的Tortoise文档。这是我见过的唯一可以解决分支机构工作问题的文档。给出的示例并没有解释为什么我在分支上修改的文件出现了树冲突。树冲突消息将需要一些时间来习惯。
看起来你在大多数情况下所做的就是标记已解决的树冲突，在这些情况下看起来树冲突只是噪音。
Mark Phippard说，较旧的服务器版本不会导致树冲突。如果您需要合并跟踪支持且服务器是1.5之前的版本，则只需要更新服务器。显然，合并跟踪是旧svn服务器中唯一缺失的东西：
http://eclipse.open.collab.net/ds/viewMessage.do?dsForumId=62&dsMessageId=332448
答案 1 :(得分：10)
svn：尝试添加已存在的树冲突
Subversion抱怨是因为在你进行了一次产生冲突的合并之后，再次进行了同样的合并。 SVN尝试添加冲突，但注意到之前的合并操作已经创建了冲突。所以它正确输出一个警告。
如果您进行合并操作并且对结果不满意，那么在尝试其他操作之前，您应首先恢复本地更改。
至于原始树冲突：要理解为什么行为与旧客户端不同以及如何解决此类冲突，您必须阅读svn书中的section on tree conflicts。 tortoiseSVN手册也有一个很好的topic on tree conflicts。
答案 2 :(得分：2)
我猜测你正在观察1.6客户端和1.3服务器之间的错误交互。 树冲突检测是1.6的新特性。此外，合并支持已更改为1.5（然后更加可用）。
我尝试将服务器和repo格式升级到1.6，尝试的另一件事是使用1.5（无树冲突）或1.4（并且没有新的合并）客户端。
同样，这是一个猜测，可能不是很有用......
答案 3 :(得分：0)
嘿伙计我有完全相同的问题，当我尝试进行svn合并时树冲突。事实证明Laurynas是完全正确的。它发生的原因是svn存储库是一个旧版本。在服务器上，我进入了目录{repopath} \ db \ format，并在其中包含的格式文件中＆＃34; 2＆＃34;。
我所做的就是做一个
svnadmin upgrade {repopath}
非常轻松。
在我这样做之后，当我尝试使用合并跟踪时，我没有再遇到树冲突了！谢谢你的提示！