问题标签 [tree-conflict]

合并时总是发生这种情况，我真的不知道为什么（我看到几个答案详细说明了几个可能的原因）但原因与我的问题无关，因为无论是什么原因导致相同文件上的“树冲突”在相同的路径中，结果总是相同的：根本不需要更改任何内容，“冲突”可以标记为已解决。

因此，每次我遇到“树冲突”时，我都必须[检查源文件，如果它不存在，] 使用 WinDiff 之类的差异工具（因为“树冲突”没有 SVN 客户端打开它的差异工具，尽管两者文件在那里），比较这两个文件以找出它们是否相同（它们几乎总是相同），如果是，只需将冲突标记为已解决，而无需进行任何更改以“解决”冲突。

显然，这是非常非常浪费时间的，而且感觉非常令人沮丧和毫无意义。

所以我想知道是否有任何方法 - 通过一些 SVN 交换机或一些 SVN 客户端或其他任何东西 - 以便在 100% 确定不需要更改任何内容的情况下不会标记树冲突为了解决冲突 - 就像我上面的例子一样。

补充：知道人们在相同文件上发生树冲突的情况对我来说也很有趣（顺便说一句，我说的是自从我创建分支以来没有人接触过的文件，既没有删除也没有重新创建，也没有修改或移动也没有别的）。因此，如果您遇到这种情况，欢迎您发表评论。

我在 svn 1.7.4/ 和乌龟 svn 1.7.6 上。我试图用谷歌搜索是什么，What is tree conflict in svn但除了一些具体问题外，找不到一些深入解释它的文章。

这是我对树冲突的理解

假设我有主干，现在我在 T1 时间从主干创建了分支 branch1。现在，如果某些开发人员在 T2 的主干下添加了一些文件或文件夹或重命名了一些文件，并且当我尝试将分支合并到主干（使用Merge using range of revisions）时，由于在源中添加了一些文件或文件夹（主干在这个案例） 。那正确吗 ？如果是，最好使用 Tortoise SVN 将更改合并回主干的方法是什么？

虽然如果在 T1 之后的分支上发生添加/删除/重命名但主干没有改变，我还会遇到树冲突吗？如果是，最好使用 Tortoise SVN 解决它的方法是什么？

SVN 中的当前项目结构

Trunk > Folder 1> it contains further folders like A, B,C

我已经从文件夹 1 创建了分支。

现在我意识到文件夹 1 是多余的。基本上结构应该

Trunk > it contains further folders like A, B,C

我打算做什么

1）首先将文件夹A，B，C复制到Trunk中。所以结构变成了这样 Trunk > Folder 1> it contains further folders like A, B,C Trunk > it also contains further folders like A, B,C

2）合并分支到主干，以便分支文件夹（A，B，C）下的修改合并到A,B,C under Trunk

3）然后从trunk中删除文件夹1

但是在第 2 步，我得到了 Tree conflict error 。我不知道为什么？

我是 SVN 的新手，我想我犯了一些错误，我不知道如何解决。我正在将我的插件上传到 WordPress。我上传了几个版本，然后意识到我正在开发的文件尚未准备好并导致问题。所以我从 Trunk 文件夹和标签版本文件夹中删除了文件，现在我收到以下错误。似乎无论我做什么我都无法修复它。

当我做 svn stat 我得到：

当我尝试提交执行 svn ci -m 'notes' 的插件时，我得到：

你可以在这里查看现在有什么：http: //plugins.svn.wordpress.org/bh-design/tags/

关于 tags/1.4/* 和我删除的电子邮件订阅文件夹有很多错误。问题是我的本地机器上没有 tags/1.4/，当我 svn up 时它没有添加它，所以我不确定这个 1.4 在哪里......

任何帮助都会很好！

开始之前的一个简短说明：“设置舞台”需要很多解释，看起来这更像是一个设计问题，而不是一个关于编程问题的问题。这个问题其实是关于SVN分支和合并的，所以请读到最后。

设想：

我有一个包含很多项目的大型 Visual Studio 解决方案。我用的是SVN，所以主干当然有我开发的生产线。这包括一个核心 DLL 程序集、一个“主”UI 用户客户端和一些“插件”程序集，这些程序集通过在核心程序集上实现接口以在 UI 中提供功能，并且还通过利用一组服务来操作为所有插件提供通用功能的方法（例如持久性逻辑操作、集中式文件存储架构的存储操作等）

随着时间的推移，我还构建了一些外部实用程序，它们必须复制插件中的许多业务逻辑。我不会详细介绍，因为它最终会分散我的主要问题，而只是想象一下，例如，处理与特定插件数据相关的集中维护操作的服务器上的预定服务。

当我最初构建这个应用程序时，我（愚蠢地）没有预料到需要集中服务层，所以我构建了核心组件（无论好坏），如上所示，与应用程序的表示层紧密集成. 换句话说，将插件与用户界面集成所需的 UI 表示逻辑以及插件执行常见插件逻辑操作所需的业务逻辑都是一个“核心”组件的一部分。因此，插件和集中式服务之间存在的许多“共享”逻辑导致了重复代码。

我决定进行主要的重构计划，将通用逻辑——与演示无关的逻辑——提取到一个“共享”程序集中。为此，我从主干上创建了一个分支。我将公共代码重新组织为“共享”程序集，并重新指向客户端应用程序（插件等）和外部服务应用程序中的所有内容以利用共享程序集。在许多情况下，我还必须重命名类以适应它们未来更通用的用途。核心组件保留在原位，仅用于代理插件和 UI 之间的表示层职责。

问题：

现在我已经成功地完成了重构，我想将分支重新集成回主干。即使在简单的情况下，合并也是一件棘手的事情，但我在这里面临的是很多树冲突，委婉地说。此外，除了驻留在一个全新的项目中之外，“共享”项目中的文件夹结构与“核心”项目中的文件夹结构有很大不同。在许多情况下，由于使用共享程序集的新机制，类位于不同的位置。

我想维护每个类的版本历史，从核心程序集中的旧家到共享程序集中的新家。此外，我想保证合并成功。这似乎很明显，但在测试整个场景的微型版本时，我永远无法以我的分支功能保持完整不变的方式解决冲突。此外，正如我之前所说，我已经重命名了一些类以适应它们更一般的角色，这使得维护版本历史变得非常棘手。

我会注意到我正在使用AnkhSVN，当您重命名文件以修复移动时，它有助于“正常”情况，但它似乎不适用于这些主要的树冲突情况。另外，我知道不同版本的 SVN 之间的合并工作方式存在差异——我相信它是 SVN 1.5 之前的版本和 SVN 1.5 之后的版本。我正在使用 SVN 1.9.3。

几个星期以来，我一直试图弄清楚这一点。我一直在翻阅SVN 书籍、TortoiseSVN 资源，以及任何我可以从谷歌搜索中找到的东西，比如this、this和this —— 还有很多很多很多其他的。我觉得我快疯了，我认为高级 SVN（和 Tortoise）不可能用传统的自学、从网络和书籍中学习的方法来学习。无论如何，我将非常感谢那里的任何见解。

当您使用 SVN 创建功能分支并计划进行主要的树更改和“移动”（即重命名）以便您可以将这些更改与主干重新集成而不会丢失任何内容时，正确的方法是什么？

以下是有关此树冲突的一些信息：

上次更新操作尝试删除/移动/重命名目录>'models'，但该目录已被编辑

冲突来源：

来源左： http://.../svn/.../models@23800

来源权利： http://.../svn/.../models@23805

svn状态：

我想保留服务器版本并丢弃本地的所有更改。

更新：

如果我使用“svn resolve --accept working models”，svn 会选择本地版本吗？

我应该怎么做？

我要做一个 TotoiseSVN 合并。我要合并的分支最近已重命名。该分支中的某些文件在重命名后已更改。当我执行测试合并时，它只显示那些文件的树冲突。但是当我真正进行合并时，它会正确合并并且看不到任何冲突。任何人都可以帮助我理解这种行为吗？

您可以看到红色的冲突文件，但在真正的合并中我们看不到这一点。

我的后备箱 (trunk/gray/catalog/web/app_code/) 和我的分支 (branches/125/gray/catalog/web/app_code/) 中有一个目录。主干和分支包含 8 个共同的文件，但分支有 20 个在主干中找不到的文件。这些文件被 SVN 添加到分支。两个目录都只包含文件作为子目录（没有子目录）。gray/catalog/web/app_code/ 使用 SVN Add 在分支和主干中分别制作。

当我尝试使用 Tortoise SVN 测试合并分支/125/gray/catalog/web/app_code/ 到 trunk/gray/catalog/web/app_code/ 时，所有常见文件都显示树冲突错误，并且分支中的文件但不在主干不会添加到主干。

如果我尝试在 gray/catalog/web/ 级别进行测试合并，则不会显示任何冲突。常见的8个文件显示为SVN添加，分支中没有主干的20个文件根本没有添加或提及。

什么可能导致这种情况？

我正在与 git 合作，每次我们尝试合并代码时都会发生树冲突。我们目前正在使用 git flow，我们通常从开发开始功能，当任务完成时，我们中的一个人将一个功能合并到另一个，然后将其合并到开发中。问题是每次我们尝试将一个特性合并到另一个特性时，我们都会在 xcode 中发生树冲突，我们不知道如何解决它。

错误消息是：“由于一个或多个树冲突，无法执行操作。”

将分支合并到主干。

获取冲突

如果我选择“标记已解决”，则 a/b 下的修改后的文件 Hello.java 将被忽略（不合并）。我应该怎么做才能将更改的文件拉到冲突树下（例如 Hello.java）？如何在这个场景中合并？

svn，版本 1.9.1 (r1698128)