为什么我在 Subversion 中遇到树冲突？

StackOverflow https://stackoverflow.com/questions/738367

  •  09-09-2019
  •  | 
  •  

题

我的主干有一个功能分支，并且定期将主干的更改合并到我的分支中，一切都工作正常。今天，我将分支合并回主干，创建分支后添加到主干的任何文件都被标记为“树冲突”。将来有办法避免这种情况吗？

我认为这些没有被正确标记。

有帮助吗？

解决方案

我发现溶液读取加里给链路（我建议遵循这种方式）。

总结，解决树冲突的提交你的工作目录与SVN客户端1.6.x版，您可以使用：

svn resolve --accept working -R .

其中.是在冲突的目录。

警告：“提交你的工作目录”是指你的沙箱结构将是你犯的一个，所以如果，例如，你从你的沙箱中删除一些文件，他们将从资源库中删除了。这仅适用于所述冲突目录。

在这种方式中，我们建议SVN来解决冲突（--resolve），接受您的沙箱（--accept working），递归（-R）内部的工作拷贝，从当前目录（.）开始。

在TortoiseSVN中，选择右键点击 “已解决”，实际上解决了这个问题。

其他提示

1.6的Subversion加入树冲突，以覆盖在目录级冲突。一个很好的例子是，当你在本地删除，然后文件的更新会带来一个文本换下来的那个文件。另一种方法是，当你你，因为你正在编辑一个文件的重命名颠覆是一种添加/删除操作。

CollabNet的Subversion的博客对树大文章冲突的。

在我的经验，SVN创建一个树冲突每当我删除文件夹。似乎没有理由。

我是唯一一个在我的代码工作 - >删除一个目录 - >提交 - >冲突

我不能等待切换到 GIT中。

我要澄清 - 我使用 Subclipse的。这可能是问题！同样，我不能等待切换...

我不知道这是发生在你，但有时我选择了错误的目录合并，我得到这个错误，即使所有的文件出现完全没问题。

示例：

合并/ SVN /项目/支链/一些分支/源 到/ SVN /项目/主干--->树冲突

合并/ SVN /项目/支链/一些分支 到/ SVN /项目/主干--->确定

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

这里发生的事情是这样的：你在你的躯干创建一个新的文件，然后你把它合并到你的分支。在合并提交该文件将在您的分支也被创建。

在合并你的分支回主干，SVN尝试再次做同样的：它把一个文件在您的分支创建，并试图在合并后备箱创建它承诺，但它已经存在！这将创建一个树冲突。

要避免这个问题的方法，是做一个特殊合并，一个的重新融合即可。你可以用--reintegrate开关实现此目的。

您可以在文档中读到这样的： http://svnbook.red -bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

  

当您的合并分支到主干，但是，基本   数学有很大的不同。您的特性分支现在是一个大杂烩   两个复制主干的修改和私有分支的变化，所以   有修订拷贝过来的没有简单的连续范围。通过   指定--reintegrate选项，你要Subversion   仔细复制只专属于您的分支这些变化。 （而在   事实上，它采用最新的树干与最新的比较确实这   支树：得到的差正好是你的分支修改）

重返分支这是非常可取删除它，否则你会不断收到treeconflicts每当你在其他方向合并后：从主干到您的分支。 （对于完全一样的理由如前所述。）

有解决的办法，但我却从来没有尝试过。您可以在这个帖子阅读： 颠覆分支重返社会V1.6 的

这可以通过不使用相同的版本的客户端遍布引起的。

使用版本1.5的客户端和朝向同一存储库版本1.6的客户可以建立这样的问题。 （I只是被咬自己。）

如果您遇到树冲突这是没有意义的，因为你没有编辑/删除/来的文件附近的任何地方，也有一个很好的机会，有一个在合并命令是错误的。

会发生什么是你以前已经合并了一堆要包括在当前合并的变化。例如，在树干有人编辑的文件，再后来将其重命名。如果您的第一个合并，你包括编辑，然后在第二合流包括编辑和重命名（本质上是删除），它也会给你一个树冲突。这样做的原因是，以前合并的编辑则显示为自己的，因此，删除将不会自动执行。

这可以在1.5推出的mergetracking是否有助于在这里1.4仓库至少，我不知道会发生。

我碰到这个问题，今天来为好，虽然我的具体问题可能是不相关的你。检查的文件列表后，我意识到我做了什么 - 我已暂时使用了一个文件一个集会从另一个组件。我做了很多改变它的，并没有想孤立SVN历史，所以在我的分支我已经从其他组件的文件夹移动的文件过来。这不是由SVN跟踪，所以它只是看起来像文件被删除，然后重新添加。这最终导致树冲突。

我通过移动回文件，提交和则解决了这个问题的合并我的分支。然后我搬到回文件之后。 :)这似乎这样的伎俩。

我也有类似的问题。只有真正为我工作的事情是与删除的冲突子目录：

svn delete --force ./SUB_DIR_NAME

然后再从另一根目录在具有它们与工作拷贝复制它们：

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

然后做

svn cleanup

和

svn add *

您可能会与最后一个警告，但不理会他们，最后

svn ci .

我有同样的问题，并通过使用这些说明重新进行合并解决它。基本上，它使用SVN的“2-URL合并”更新trunk到您的分支的当前状态，而不会打扰太多太多关于历史和树冲突。从手动固定114个树冲突保存箱。

我不知道，如果它保留了历史，也是一想，但它是值得的，在我的情况。

我有时遇到的场景：

假设有一躯干，从其中创建发布分支。主干一些变化（特别是打造“一些-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

所以，你需要明确地合并其在创造功能之前，主干所做提交/修复其合并功能/修复分支之前创建的“一些-DIR”目录分支。

我常常忘记，在GIT中是没有必要的。

直到今天，至少从 3 个月前开始，我在尝试将分支合并回主干时经常遇到数百个树冲突（使用 乌龟SVN 1.11）。顺便说一句，无论是否重新调整基础。我从 2004 年的 v1 版起就一直在使用 TortoiseSVN，并且我一直都在重新集成分支。我想最近一定发生了什么事情吧？

所以今天我进行了这个简单的实验，我发现了造成这些疯狂冲突的原因：

  1. 我叉掉了后备箱@393；
  2. 我随机修改了数十个文件，并创建了新文件；
  3. 我承诺了。现在@395（一位同事在394处分叉以执行他自己的事情）。
  4. 然后我尝试将分支重新集成到主干中，仅进行测试；遵循 TortoiseSVN 在向导中的建议：“要合并所有修订（重新集成），请将该框留空”。为了实现这一点，我右键单击 trunk 文件夹，然后选择“TortoiseSVN > Merge, from /path/to/branch”，然后我 将转速范围留空, ，按照对话框中的建议。

讨论： （见附件）

所有修订...什么？ 我知道的很少 客户一定指的是“目标的所有修订！ （主干）”，因为在重新集成该分支的过程中，我看到了“合并修订 1-HEAD”！我的天啊。可怜的魔鬼，你会摔死在这里。那个分支出生于@393，看在上帝的份上，你难道看不到它的出生证明吗？ this is why so many conflicts occurred: SVN-cli is going on a foolish spree from revision 1

解决：

  1. 与专家的建议相反，请指定一个范围，涵盖...分支生命周期的所有修订！所以， 394头;
  2. 现在再次运行合并测试，并获取一支雪茄。（see second attachment).

道德：我无法理解为什么他们仍然没有修复这个错误，因为这是一个错误，我很抱歉。我应该花时间向他们报告此事。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top