为什么我在Subversion中得到树冲突?

我在主干中有一个特性分支，并定期将主干中的更改合并到分支中，一切都运行正常。今天，我将分支合并回主干中，在创建分支后添加到主干中的任何文件都被标记为“树冲突”。将来有办法避免这种情况吗?

我认为他们没有被正确标记。

当前回答

我也遇到过类似的问题。唯一对我有用的是删除冲突的子目录:

svn delete --force ./SUB_DIR_NAME

然后从工作副本的另一个根目录中再次复制它们:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

然后做

svn cleanup

and

svn add *

你可能会得到最后一个警告，但忽略它们，最后

svn ci .

其他回答

如果因为没有编辑/删除/接近文件而遇到树冲突，那么合并命令中也很有可能出现错误。

可能发生的情况是，您之前已经合并了当前合并中包含的一些更改。例如，在trunk中有人编辑了一个文件，然后重新命名它。如果在第一次合并中包含编辑，然后在第二次合并中同时包含编辑和重命名(本质上是删除)，它也会给您一个树冲突。这样做的原因是，先前合并的编辑将显示为您自己的编辑，因此删除将不会自动执行。

这至少可以发生在1.4版本的存储库中，我不确定1.5版本中引入的合并跟踪在这里是否有帮助。

我不知道这是否发生在你身上，但有时我选择了错误的目录合并，我得到这个错误，即使所有的文件看起来完全正常。

例子:

合并/ svn /项目/部门/分公司/来源 to /svn/Project/trunk——>树冲突

合并/ svn /项目/部门/分公司 to /svn/Project/trunk——> OK

这可能是一个愚蠢的错误，但它并不总是显而易见的，因为你认为它是更复杂的东西。

Subversion 1.6添加了树冲突来覆盖目录级别的冲突。一个很好的例子是，当您在本地删除一个文件时，更新会尝试对该文件进行文本更改。另一种情况是，当您对正在编辑的文件进行subversion重命名时，因为这是一个添加/删除操作。

CollabNet的Subversion博客上有一篇关于树冲突的很棒的文章。

我通过Gary给出的链接找到了解决方案(我建议按照这种方式进行)。

通过汇总来解决向SVN客户端1.6提交工作目录的树冲突。X你可以使用:

svn resolve --accept working -R .

在哪里。目录冲突。

警告:“提交你的工作目录”意味着你的沙盒结构将是你要提交的，因此，例如，如果你从你的沙盒中删除了一些文件，它们也会从存储库中删除。这只适用于冲突的目录。

通过这种方式，我们建议SVN解决冲突(——resolve)，从当前目录(.)开始递归地(-R)接受沙箱中的工作副本(——accept working)。

在TortoiseSVN中，右键单击“Resolved”，实际上解决了这个问题。

我也遇到过类似的问题。唯一对我有用的是删除冲突的子目录:

svn delete --force ./SUB_DIR_NAME

然后从工作副本的另一个根目录中再次复制它们:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

然后做

svn cleanup

and

svn add *

你可能会得到最后一个警告，但忽略它们，最后

svn ci .

推荐文章