为什么我在Subversion中遇到树冲突？
Gre*_*reg 350 svn merge tree-conflict
我有一个我的行李箱的功能分支,并定期将我的行李箱的变化合并到我的分支机构中,一切正常.今天我将分支合并回到主干中,在创建分支后添加到主干的任何文件都被标记为"树冲突".有没有办法在将来避免这种情况？
我不认为这些被正确标记.
gic*_*ppa 395
我发现解决方案正在阅读Gary给出的链接(我建议按照这种方式).
总结为解决使用SVN客户端1.6.x 提交工作目录的树冲突,您可以使用:
svn resolve --accept working -R .
.冲突目录在哪里.
警告:"提交您的工作目录"意味着您的沙箱结构将是您提交的那个,因此,例如,如果您从沙箱中删除了某个文件,它们也将从存储库中删除.这仅适用于冲突的目录.
通过这种方式,我们建议SVN解决冲突(--resolve),从当前目录()开始--accept working,以递归方式(-R)接受沙箱()内的工作副本..
在TortoiseSVN中,右键单击选择"已解决",实际上解决了这个问题.
- 这不是盲目地接受工作副本吗？我的意思是我觉得我不知道这些冲突存在哪些问题,但如果我只是解决并接受工作,那么它不仅仅会抹去其他人的工作吗？ (39认同)
- 这样你建议svn来解决冲突(--resolve),接受你的沙箱里面的工作副本(--accept working),递归(-R),从当前目录开始(.)HTH (32认同)
- 在TortoiseSvn中,右键单击选择"已解决",实际上解决了这个问题. (22认同)
- 导致这种情况发生的一个原因可能是您确定了一个您认为不再需要的目录,但其他人添加了一个需要的新文件.更新工作副本时,您应该遇到树冲突.如果您只是盲目地接受您的解决方案(删除目录),那么您将删除该人的文件.没有神奇的"做正确的事"按钮.您必须了解您正在做什么,为什么与最新版本冲突,以及如何正确解决它. (10认同)
- @TWiStErRob,我认为这种症状表明SVN作为版本控制工具固有的问题.就个人而言,将来"避免"这个问题的方法是使用`git`.由于这对于提问者来说很可能不是一个实际的选择,因此处理这个答案描述的情况是最好的选择. (5认同)
- 对于git来说也是一个问题,如果有人删除了你要添加文件的文件夹,git可以做什么？回答:没有用,它需要人为干预来说"这就是我们的意思",这不是什么svn,git或任何其他SCM可以自己决定的. (2认同)
- 我做了这个,我认为我必须错误地完成它,而有问题的文件不存在.现在他们失踪了,而我似乎没有把它们带回来.重写`--accept theirs-full`:nope; `svn revert`:不.`rm -rf`他们所在的目录和'svn update`它:nope.我知道,我可以逐字阅读手册并攀登一个巨大的学习曲线,以了解实际发生了什么但是更容易核实整个回购并再次检查它,这最终是唯一有效的.这个特征是地雷.Mercurial从现在开始一路走来. (2认同)
小智 33
根据我的经验,SVN会创建一个树冲突,无论我删除一个文件夹.似乎没有理由.
我是唯一一个在我的代码上工作的人 - >删除目录 - >提交 - >冲突!
我等不及要切换到Git了.
我应该澄清 - 我使用Subclipse.那可能就是问题!再一次,我迫不及待想要切换......
- 我对NetBeans和SVN也有同样的问题.删除目录 - >冲突. (3认同)
- 来自SVN命令行客户端的问题相同,所以它不是Eclipse. (2认同)
- 同样的问题......非常烦人......必须REVERT,更新,删除和提交...... (2认同)
- 当我遇到树冲突时，我发现了 IntelliJ Idea 的一个绝妙技巧。我搁置所有更改（这与创建我的更改补丁然后回滚它们相同）。然后我执行 svn update 以从 Subversion 获取最新更改。之后，我取消了我的更改（与应用补丁相同）和中提琴！ (2认同)
小智 28
我不知道你是否发生了这种情况,但有时我会选择错误的目录进行合并,即使所有文件看起来都完全正常,我也会收到此错误.
例:
Merge/svn/Project/branches/some-branch/sources to/svn/Project/trunk --->树冲突
合并/ svn/Project/branches/some-branch到/ svn/Project/trunk --->好的
这可能是一个愚蠢的错误,但它并不总是很明显,因为你认为它更复杂.
Gáb*_*yal 15
这里发生的事情如下:您在主干上创建一个新文件,然后将其合并到您的分支中.在合并提交中,此文件也将在您的分支中创建.
当您将分支合并回主干时,SVN会再次尝试执行相同的操作:它会看到您的分支中创建了一个文件,并尝试在合并提交中在您的主干中创建它,但它已经存在!这会造成树冲突.
避免这种情况的方法是进行特殊合并,重新整合.您可以通过--reintegrate开关实现此目的.
您可以在文档中阅读:http: //svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate
然而,当你的分支合并回主干时,基础数学是完全不同的.您的功能分支现在是重复主干更改和专用分支更改的混搭,因此没有简单的连续修订版本可供复制.通过指定--reintegrate选项,您要求Subversion仅仔细复制您的分支特有的更改.(事实上,它通过将最新的树干树与最新的树枝树进行比较来实现这一点:产生的差异正是你的树枝变化!)
重新集成分支后,最好将其删除,否则每当您向另一个方向合并时,您将不断遇到树冲突:从主干到分支.(原因与前面描述的完全相同.)
还有一种解决方法,但我从未尝试过.你可以在这篇文章中阅读它:v1.6中的Subversion branch reintegration
- Upvoted,因为很多人仍然使用subversion <1.8 (8认同)
直到今天，至少从 3 个月前开始，我在尝试将分支合并回主干时经常遇到数百个树冲突（使用TortoiseSVN 1.11）。无论是否重新定位，顺便说一句。从 2004 年的 v1 开始，我就一直在使用 TortoiseSVN，而且我一直在重新整合分支。我想一定是最近发生了什么事情吧？
所以今天我进行了这个简单的实验，我发现了造成这些疯狂冲突的原因：
- 我分叉了后备箱@393；
- 我随机修改了几十个文件，也创建了新的文件；
- 我答应了。现在@395（一位同事在 394 分叉以执行他自己的工作）。
- 然后我尝试将分支重新整合回主干，仅测试；遵循 TortoiseSVN 在向导中的建议：“要合并所有修订（重新集成），将该框留空”。为此，我右键单击主干文件夹，然后选择“TortoiseSVN > Merge, from /path/to/branch”，然后按照对话框中的建议将 rev range 留空。
讨论：（见附件）
所有的修订……什么？我几乎不知道客户端一定是指“目标的所有修订版！（主干）”，因为在重新集成该分支的过程中，我看到了“合并修订版 1-HEAD”！我的天啊。可怜的恶魔，你要在这里摔死了。那个分支出生在@393，看在上帝的份上，你不能读它的出生证明吗？
解析度：
- 与向导的建议相反，请指定一个范围，该范围涵盖...分支生命周期的所有修订版！因此，394-HEAD；
- 现在再次运行该合并测试，并获得一支雪茄。(
）。
道德： 我无法理解为什么他们仍然没有修复那个错误，因为它是一个，我很抱歉。我应该花时间向他们报告此事。