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

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


当前回答

直到今天,至少从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头; 现在再次运行合并测试,并获得一支雪茄。()。

道德: 我不能理解为什么他们还没有修复这个错误,因为这是一个,对不起。 我应该花时间跟他们汇报。

其他回答

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

例子:

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

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

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

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

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

I came across this problem today as well, though my particular issue probably isn't related to yours. After inspecting the list of files, I realized what I had done -- I had temporarily been using a file in one assembly from another assembly. I have made lots of changes to it and didn't want to orphan the SVN history, so in my branch I had moved the file over from the other assembly's folder. This isn't tracked by SVN, so it just looks like the file is deleted and then re-added. This ends up causing a tree conflict.

我通过将文件移回,提交,然后合并我的分支来解决这个问题。然后我把文件移了回来。:)这似乎奏效了。

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

svn delete --force ./SUB_DIR_NAME

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

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

然后做

svn cleanup

and

svn add *

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

svn ci .

我遇到了同样的问题,并通过使用这些指令重新做合并来解决它。基本上,它使用SVN的“2-URL合并”将主干更新到分支的当前状态,而不用担心历史和树冲突。让我不用手动修复114棵树的冲突。

我不确定它是否像人们希望的那样保存了历史,但对我来说是值得的。