我在主干中有一个特性分支,并定期将主干中的更改合并到分支中,一切都运行正常。今天,我将分支合并回主干中,在创建分支后添加到主干中的任何文件都被标记为“树冲突”。将来有办法避免这种情况吗?
我认为他们没有被正确标记。
我在主干中有一个特性分支,并定期将主干中的更改合并到分支中,一切都运行正常。今天,我将分支合并回主干中,在创建分支后添加到主干中的任何文件都被标记为“树冲突”。将来有办法避免这种情况吗?
我认为他们没有被正确标记。
当前回答
如果因为没有编辑/删除/接近文件而遇到树冲突,那么合并命令中也很有可能出现错误。
可能发生的情况是,您之前已经合并了当前合并中包含的一些更改。例如,在trunk中有人编辑了一个文件,然后重新命名它。如果在第一次合并中包含编辑,然后在第二次合并中同时包含编辑和重命名(本质上是删除),它也会给您一个树冲突。这样做的原因是,先前合并的编辑将显示为您自己的编辑,因此删除将不会自动执行。
这至少可以发生在1.4版本的存储库中,我不确定1.5版本中引入的合并跟踪在这里是否有帮助。
其他回答
Subversion 1.6添加了树冲突来覆盖目录级别的冲突。一个很好的例子是,当您在本地删除一个文件时,更新会尝试对该文件进行文本更改。另一种情况是,当您对正在编辑的文件进行subversion重命名时,因为这是一个添加/删除操作。
CollabNet的Subversion博客上有一篇关于树冲突的很棒的文章。
我不知道这是否发生在你身上,但有时我选择了错误的目录合并,我得到这个错误,即使所有的文件看起来完全正常。
例子:
合并/ svn /项目/部门/分公司/来源 to /svn/Project/trunk——>树冲突
合并/ svn /项目/部门/分公司 to /svn/Project/trunk——> OK
这可能是一个愚蠢的错误,但它并不总是显而易见的,因为你认为它是更复杂的东西。
我有时会遇到这样的情况:
假设您有一个主干,从中创建了一个发布分支。在主干上做了一些更改之后(特别是创建“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中是不必要的。
根据我的经验,每当我删除一个文件夹时,SVN都会产生树冲突。似乎没有什么理由。
我是唯一一个工作在我的代码->删除目录->提交->冲突!
我迫不及待地想切换到Git。
我应该澄清一下,我使用Subclipse。这可能就是问题所在!再说一次,我迫不及待地想换……
直到今天,至少从3个月前开始,我在尝试将一个分支合并回主干(使用TortoiseSVN 1.11)时经常遇到数百个树冲突。顺便说一句,不管是否重制。 我从2004年的TortoiseSVN v1开始就一直在使用它,而且我一直在重新集成分支。我想最近一定发生了什么事吧?
所以今天我做了一个简单的实验,我发现了是什么导致了这些疯狂的冲突:
I forked off the trunk @393; I modified tens of files randomly, as well as creating new ones; I committed. Now @395 (a colleague forked off at 394 to perform his own stuff). Then I tried to reintegrate the branch back into the trunk, test only; following TortoiseSVN's recommendation in the wizard: "to merge all revisions (reintegrate), leave that box empty". To achieve this, I right-clicked onto the trunk folder, and chose "TortoiseSVN > Merge, from /path/to/branch", and I left the rev range empty, as advised on the dialog.
讨论:(见附件)
所有修改……的什么?我不知道客户肯定指的是“所有修订的目标!”(主干)”,因为,在重新集成该分支的过程中,我看到提到“合并修订1-HEAD”!我的天啊可怜的魔鬼,你会死在这里的。那个分支是@393出生的,看在上帝的份上,你看不懂它的出生证明吗?
解决方法:
与wiz的建议相反,请指定一个范围,涵盖…的所有修订。树枝的生命!因此,394头; 现在再次运行合并测试,并获得一支雪茄。()。
道德: 我不能理解为什么他们还没有修复这个错误,因为这是一个,对不起。 我应该花时间跟他们汇报。