问题标签 [tree-conflict]

我正在使用 Eclipse 8.6 和 Subclipse 1.6，以及 svn 1.6.x 服务器。我创建了一个分支，对分支和主干进行了一些更改，现在我正在尝试从主干合并到这个分支。我得到的只是分支根目录下每个目录和每个文件的树冲突。即使在我的测试项目中我只编辑了一个文件，我也得到了这一点。问题是我不明白这些树冲突是什么意思，因为我没有改变任何东西。我只更改了一个文件进行测试，我应该在合并期间获取文件更新，但这只是被忽略了。我在合并窗口中看到的只是根目录下每个目录和每个文件的树冲突图标。同样在树冲突窗口下，它告诉我每个树冲突的“本地添加，合并时的传入添加”。

我正在尝试自动化一些 Subversion 进程，但遇到了冲突问题。当我合并两个分支时，有时我会遇到树冲突和常规（文本）冲突。我希望能够使用存储库副本解决所有问题：

但是如果有树冲突，它会对我大喊大叫，说我必须将它们解决到工作状态。

svn：警告：树冲突只能解决到“工作”状态；“文件”未解决

有没有一种简单的方法可以将树冲突解决为“工作”，以便我可以继续解决与他们的完整的文本冲突？或者也许是另一种完全实现我的目标的方法？我希望通过 Windows 命令行来执行此操作。谢谢！

Subversion 服务器是 1.6.6 版本

我正在使用 CollabNet Subversion 命令行客户端 v1.6.13（适用于 Windows）

这是我的场景：

假设我们有一个包含以下内容的 SVN 存储库： myfolder myfolder\file.txt

现在我创建了这个 repo 的两个结帐，co1 和 co2。

在 co1 中我们修改 file.txt。在二氧化碳中，我们：

• svn 删除我的文件夹
• svn 提交
• 创建一个名为 myfolder 的新文件夹
• svn 添加我的文件夹
• svn 提交

现在，如果我尝试在 co1 中进行更新，我会遇到树冲突：

我想保留我的文件夹和修改后的文件，所以我解决了树冲突：

现在，如果我尝试提交，我会得到“svn: Directory '/myfolder' is out of date”。如果我尝试使用 svn up myfolder 解决此问题，我会再次遇到树冲突：

好的，所以我们再次尝试 svn resolve --accept 工作文件夹。但是我们仍然无法提交，我们得到相同的消息“svn: Directory '/myfolder' is out of date”，如果我们执行 svn up myfolder，我们会回到最后的树冲突。

解决此类冲突的正确程序是什么（当我们希望保留 myfolder 及其更改时）？

编辑：Windows cmd 行脚本来说明：

这是运行该脚本的输出（注意最后的提交失败）：

TortoiseSVN 可以使用编辑冲突窗口帮助解决多种树冲突。

问题是，在“ ... on merge ”冲突类型的情况下，TortoiseSVN 无法猜测需要合并哪些文件。

例如，（案例：本地丢失，更新时传入删除）

• 开发主干的开发人员 A 修改文件 Foo.c 并将其提交到存储库。
• 我正在处理分支将文件 Foo.c 移动到 Bar.c 并将其提交到存储库。

开发人员 A 对我的分支工作副本的更改合并会导致树冲突：

• Bar.c 已经在我的工作副本中，状态为“正常”
• Foo.c 被标记为缺少树冲突

在大多数情况下，我需要将开发人员 A 对 Foo.c 的更改合并到重命名的 Bar.c 中。

但是我该怎么做呢？

我的分支 WC 中没有包含开发人员 A 更改的文件 Foo.c。

TortoiseSVN 帮助说“ <em>请注意，如果您从存储库中复制丢失的文件，然后标记为已解决，您的副本将再次被删除。你必须先解决冲突。”</p>

那么，我是否需要 chechout trunk才能访问 Foo.c 文件进行合并？有没有更简单的方法来解决这个问题？

这个问题（TortoiseSVN 如何解决树冲突）对我和我们的开发人员来说非常关键。

你可以帮帮我吗？

1）我有一个树干并从中创建了一个分支。

2）主干包含一个目录A，在分支中这个目录被重命名为B。

3) 现在在后备箱中，我们不小心对 A 中的文件 F 进行了更改。

4）重新整合分支会产生树冲突

5) 聪明我恢复了对主干中文件 F 的更改-但这不是解决方案，因为在合并期间颠覆仍然尝试执行更改然后恢复它们。这仍然导致冲突。

问题-A 部分：处理这种情况的正确解决方案是什么？只是接受冲突并手动处理它？

问题-B 部分：如果文件位于已在分支中重命名的目录中，subversion 通常不能合并文件吗？

（我正在使用 Subversion 1.6 和 Tortoise）

在 SVN 中，我在合并两个分支时会发生树冲突。出现树冲突是因为我在两个分支中添加了相同的文件或相同的目录。这里提出了很多相同的问题：

关于邪恶双胞胎树冲突的其他 Stackoverflow 问题

但是我需要接受传入的添加。Subversion 只允许我接受存储库的工作状态。所以我希望我可以从 B1 合并到 B2，删除 B2 中本地添加的文件，告诉 svn 将 B1 中的文件添加（重新合并？）到 B2，然后提交合并。是否有可能解决传入版本的邪恶孪生冲突？

这里的重点是接受传入的版本，以便下次从 B1 合并到 B2 时，我将自动合并更改，而不必进行相反的 B2->B1 合并。

我们有 2 名开发人员使用 EGit。一种适用于 Windows，一种适用于 Linux

我们制定了如下合作政策：

• 有一个中央（裸）存储库
• 最初，每个开发人员都从中央存储库中签出并在本地工作。
• 当两者需要同步工作时，我们从/向中央存储库拉/推。

我们按照我们的想法使用中央存储库，有了它，我们将来可以轻松地与团队中的更多开发人员协作。

一切正常，直到我们检测到当一个开发人员修改已被另一个开发人员移动到另一个目录的文件时根本没有冲突。以下是步骤：

• 一位开发人员，将文件移动到另一个位置；将其提交到他的本地存储库；将其推送到中央存储库。
• 另一个更改该（相同）文件的内容；将其提交到他的本地存储库。拉取中央存储库。

我们预计当第二个开发人员进行“拉动”时会有冲突报告。但没有冲突。他的工作目录（和他的本地存储库）中出现了 2 个文件：

• 他修改的那个
• 以及第一个开发人员已移至另一个目录的那个。

谁能告诉我们我们的错误是什么？

我们的工作方式是否违反了 git 的设计？

我们是 git 新手（对 CVCS 很熟悉）。遇到这个问题，我们非常担心，因为这意味着我们团队的工作很难合并。我们认为我们必须做错事。感谢您为我们澄清。

我对主干的工作副本进行了更改。然后，我想切换到一个不同的分支，以便我可以提交它。我做到了，现在我的项目一团糟。我切换到的分支位于主干后面，并且缺少我对其进行修改的文件。沮丧，我切换回后备箱。

现在我在几个地方有树冲突，说“本地编辑，切换时传入删除”。由于冲突，我不能提交这些。我能看到的唯一选择是恢复我的本地更改，或者基本上重新签出整个项目并丢失我的所有更改。

另一个问题 - 我恢复（并删除）了一个存在这种树冲突的文件夹。所以现在，我可以看到存储库中存在该文件夹，但它已从我的本地项目中消失，并且更新不会将它带入我的工作副本。这里发生了什么事？1. 它存在于 repo 中，2. 它不存在于我的工作副本中，因为我刚刚删除了它，以及 3. 更新不会将它带入我的工作副本。为什么是这样？

为什么这么难？我有本地更改，我想提交它们。我不明白为什么我切换到另一个分支并再次返回很重要。如果我切换到的分支上不存在该文件，为什么我不能将我的文件提交到分支以便它存在？

这是 Eclipse 为我提供的其中一个树冲突，这是对我切换到的分支上不存在的文件的本地更改。我假设它想在我切换时删除文件，因为它不在分支中。那么我现在该如何解决这个问题呢？我真正想做的是将它添加到分支并提交我的更改，但我不能，因为现在有冲突！

它给我的唯一选择是还原、删除或比较，所有这些都是不可接受的。我有很多本地更改！

我有一个 SVN 存储库，其中具有以下结构：

我正在尝试对 dir1 进行一些重大更改，因此我为它创建了一个新分支，因为 dir2 非常重，并且需要很长时间来检查我创建的每个新分支。所以我这样做了：

到目前为止没有问题。每当我尝试再次将主干合并到新分支时，就会出现问题。

当我这样做时，我会得到这样的东西：

一个重要的细节是我试图在创建并签出分支后立即合并，因此分支或主干没有任何变化。

那么，我在这里做错了什么？为什么我会收到所有这些树冲突？

提前致谢！

从主干合并到 SVN 树中的开发分支时出现问题。

该项目的历史是这样的。它从一个树干开始。关于修订版 207，创建了第一个分支。然后，在修订版 331 中，感兴趣的分支从主干中分离出来。

我们现在处于修订版 384。331 之间的大部分更改是在感兴趣的分支上进行的，但少数是在主干上独立进行的。

为了使分支与主干保持一致，我想从主干合并到其中。所以我适时地这样做了：

但是，我发现各种冲突都在出现。我可能理解一些冲突，但树中的几乎所有目录和文件都会受到影响。

更糟糕的是，这些所谓的冲突中的大多数实际上是在 207 和 331 之间提交到主干的更改，因此已经合并到分支中，自从分支从主干分离后就一直存在。

比这更糟糕的是，许多所谓的冲突是树冲突，涉及被删除或重命名的文件，再次在 207 和 331 之间。因为它们不再存在于分支上，而且确实不应该存在于那里，我看不到任何解决问题的方法。

修复很复杂，因为对于几乎所有文件，分支都是正确的，因此合并，然后接受分支副本，让我没有什么可提交的，所以服务器永远不会得到合并实际上已经执行的提示出去。

我已经尝试了几件事来解决它：

在我看来，这并没有做任何相关的事情。

问题仍然存在于结帐的新副本中。

有趣的是，所谓的“仅记录”合并也试图更改我本地副本中的文件！

这产生了一大堆冲突和树冲突，即使在我与仅记录合并进行斗争之后，煞费苦心地解决了它（仅记录合并）应用的更改。

我还应该说，当我开始时，我的客户端运行的是 1.6.17，服务器运行的是 1.4.6。但是，服务器后来也升级到了 1.6.17，问题依然存在。

人们有什么办法可以解决这个问题吗？进行完全合并和逐个解析文件将非常耗时，而且在这一点上 - 出于显而易见的原因 - 我什至不相信下次我的 SVN 不会只是尝试使用相同的东西我又来了。