我在主干中有一个特性分支,并定期将主干中的更改合并到分支中,一切都运行正常。今天,我将分支合并回主干中,在创建分支后添加到主干中的任何文件都被标记为“树冲突”。将来有办法避免这种情况吗?
我认为他们没有被正确标记。
我在主干中有一个特性分支,并定期将主干中的更改合并到分支中,一切都运行正常。今天,我将分支合并回主干中,在创建分支后添加到主干中的任何文件都被标记为“树冲突”。将来有办法避免这种情况吗?
我认为他们没有被正确标记。
当前回答
我遇到了同样的问题,并通过使用这些指令重新做合并来解决它。基本上,它使用SVN的“2-URL合并”将主干更新到分支的当前状态,而不用担心历史和树冲突。让我不用手动修复114棵树的冲突。
我不确定它是否像人们希望的那样保存了历史,但对我来说是值得的。
其他回答
我不知道这是否发生在你身上,但有时我选择了错误的目录合并,我得到这个错误,即使所有的文件看起来完全正常。
例子:
合并/ svn /项目/部门/分公司/来源 to /svn/Project/trunk——>树冲突
合并/ svn /项目/部门/分公司 to /svn/Project/trunk——> OK
这可能是一个愚蠢的错误,但它并不总是显而易见的,因为你认为它是更复杂的东西。
这可能是由于没有在所有地方使用相同版本的客户端造成的。
使用版本1.5的客户端和版本1.6的客户端使用同一个存储库会产生这种问题。(我自己也被咬了。)
我通过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 .
我有时会遇到这样的情况:
假设您有一个主干,从中创建了一个发布分支。在主干上做了一些更改之后(特别是创建“some-dir”目录),你创建了一个特性/修复分支,你想稍后将其合并到发布分支中(因为更改足够小,而且特性/修复对于发布非常重要)。
trunk -- ... -- create "some-dir" -- ...
\ \-feature/fix branch
\- release branch
如果你尝试将特性/修复分支直接合并到发布分支中,你会得到一个树冲突(即使目录甚至不存在于特性/修复分支中):
svn status
! C some-dir
> local missing or deleted or moved away, incoming file edit upon merge
因此,在创建feature/fix分支之前,你需要显式地合并在trunk上完成的提交,该分支在合并feature/fix分支之前创建了“some-dir”目录。
我经常忘记这一点,因为这在git中是不必要的。