我在我的代码分支上开发功能,并定期将主干的更改合并到我的分支中,一切都很顺利。今天,当我尝试将分支合并回主干时,自从创建我的分支后添加到主干的任何文件都被标记为“树冲突”。是否有办法避免这种情况发生?
我认为这些没有被正确地标记。
我在我的代码分支上开发功能,并定期将主干的更改合并到我的分支中,一切都很顺利。今天,当我尝试将分支合并回主干时,自从创建我的分支后添加到主干的任何文件都被标记为“树冲突”。是否有办法避免这种情况发生?
我认为这些没有被正确地标记。
我通过Gary提供的链接找到了解决方案(并建议按照此方式进行)。
总结一下,要使用SVN客户端1.6.x将您的工作目录与提交解决树冲突,您可以使用:
svn resolve --accept working -R .
其中.
是冲突的目录。
警告: “提交你的工作副本”意味着你要提交的是你的沙盒结构,因此如果你在沙盒中删除了某些文件,则它们也将从存储库中被删除。这仅适用于有冲突的目录。
通过这种方式,我们建议SVN解决冲突(--resolve
),接受你的沙盒中的工作副本(--accept working
),递归地(-R
)从当前目录(.
)开始。
在TortoiseSVN中,在右键单击后选择“已解决”,实际上可以解决此问题。
svn rm
命令删除了一个您认为不再需要的目录,但其他人添加了一个新文件,这个文件是必需的。当您更新工作副本时,会出现树冲突。如果您盲目地接受自己的解决方案(删除目录),那么您将删除该文件。没有魔法“做正确事情”的按钮。您必须理解自己正在做什么,为什么会与最新版本发生冲突,以及如何正确解决它。 - bambamsgit
。但鉴于询问者很可能无法采用这种实用选项,那么按照这个答案所描述的方式来处理情况是最好的选择。 - Jess TelfordSubversion 1.6增加了树冲突(Tree Conflicts)来处理目录级别的冲突。一个很好的例子是当你本地删除一个文件,然后更新尝试将该文件的文本更改下载下来时。另一个例子是当你正在编辑的文件被重命名为子版本控制中的Add/Delete操作。
CollabNet的Subversion博客有一篇关于树冲突的精彩文章。
我不知道这是否发生在你身上,但有时我选择错误的目录进行合并,即使所有文件看起来完全正常,也会遇到以下错误:
例如:
将 /svn/Project/branches/some-branch/Sources 合并到 /svn/Project/trunk ---> 树冲突
将 /svn/Project/branches/some-branch 合并到 /svn/Project/trunk ---> OK
这可能是一个愚蠢的错误,但并非总是显而易见,因为你认为它更加复杂。
--reintegrate
开关来实现这一点。然而,当将分支合并回主干时,底层数学计算方式完全不同。您的功能分支现在是主干更改和私有分支更改的混合体,因此没有简单的连续修订范围可供复制。通过指定 --reintegrate 选项,您要求 Subversion 仔细地复制仅与您的分支相关的更改。(事实上,它通过比较最新的主干树和最新的分支树来执行此操作:得到的差异正是您的分支更改!)
重新集成分支后,强烈建议将其删除,否则每次从主干向分支合并时都会出现树冲突。解决方法与之前描述的完全相同。这可能是因为客户端版本不统一造成的。
使用1.5版本的客户端和1.6版本的客户端连接同一个仓库会导致这种问题。(我自己刚刚遇到了这个问题。)
所有修订版本...是什么?我毫不知情,客户一定是在指 "目标的所有修订版本!(主干)",因为在重新集成该分支的过程中,我看到了提到 "合并修订版本 1-HEAD" 的内容!天哪。可怜的魔鬼,你正在坠入死亡之中。那个分支诞生于第393个版本,你不能读取它的出生证明吗?
解决方案:
寓意: 我无法理解为什么他们还没有修复那个漏洞,因为它确实存在,我很抱歉。 我应该花时间向他们报告这个问题。
我曾经遇到过类似的问题。唯一真正起作用的方法是使用以下命令删除冲突的子目录:
svn delete --force ./SUB_DIR_NAME
然后从另一个根目录中复制它们到具有这些文件的工作副本中:
svn copy ROOT_DIR_NAME/SUB_DIR_NAME
然后执行
svn cleanup
并且
svn add *
你可能会在最后一个得到警告,但只需忽略它们,最终完成
svn ci .