svn合并源和目标问题

Question

我正在使用SVN合并（两种不同的树）将树干合并到功能分支。

我选择来源为躯干和目标为featurebranch并从featurebranch本地工作区（黄金，精确复制的内容是在SVN）这样做。

我在featurebranch中有一个新文件file1.xml，它不在trunk中。合并时，我得到一个树冲突说合并试图添加新文件，但它已经在本地。

我的问题是，为什么当我的源是没有这个文件干线合并甚至担心在功能分支中的新文件。

我想在签入之前确保合并正确发生。任何帮助，高度赞赏。

Answer 1

注：当你的分公司不能直接从主干创建这个答案才适用。当从主干分支，看到@Ben

合并的答案两个不同的树是被解读为DIFF和应用。如果你想把分支和树干放在同一层，你需要在分支和树干之间进行差异化，并将它应用到分支（基本上是你的工作副本）。这意味着，source =你的分支和target = trunk。

实施例：

svn merge https://svn/repo/branch https://svn/repo/trunk c:\svn\branch 

此命令将采取分支和躯干之间的diff和应用的差异来工作副本分支。 （分支工作副本现在将与主干一样）

如果要将在trunk中完成的更改应用于分支（并且它是无基本合并），则需要指定要合并的修订的范围。

一个例子：

svn merge -r 10:HEAD https://svn/repo/trunk c:\svn\branch 

这将需要HEAD版本和躯干的修订10之间的差异并应用到分支。基本上应用这两个修订之间所做的更改。我怀疑这是你想要做的。

我建议你阅读http://svnbook.red-bean.com/en/1.8/svn.branchmerge.advanced.html和命令行做合并。 TortoiseSVN合并对话是一团糟。

Answer 2

通过使用“两种不同的树”合并而不是简单的“正常”合并，您正在使事情变得复杂。

你通过使用“两种不同的树”告诉SVN的是“采取所需的变化以获取trunk并将其更改为我的分支，并将这些更改应用于我的工作副本”。这不是你想要的，因为这样你就可以撤消主干上的任何更改，然后重做所有分支更改。

与之相反，我认为，在相反的情况下，“撤消我的分支上的所有更改，并在主干上执行所有更改，以使我的工作副本与主干匹配”。

如果我明白了，你真正想要的是“从我分支以来发生的所有干线变化，并将它们应用到我的工作副本”。为此，您需要将主干合并到您的工作副本。您的分支的URL根本不会出现在合并命令中。这是SVN book中记录的第一种合并形式。

Answer 3

你没有给我们太多有关正在发生的事情的信息。如果您的方案中有更详细的信息，以及您正在收到的错误消息，您将很高兴。你有没有做一个新的结账？你用什么命令来进行合并？你有什么版本的Subversion客户端和服务器？

否则，我们没有太多的办法来确定您的问题。将主干合并到来自主干的功能分支中通常应该合并，没有任何问题。

我有第一个问题是你如何创建你的分支。当你在Subversion中创建一个分支，你应该在URL形式使用svn copy创建：

$ svn copy --parent $REPO/trunk $REPO/branches/feature 

我见过人们分支通过创建通过svn mkdir一个分支，那么他们想要的文件复制这个分支的，然后将所有这些文件添加到分支上。 Subversion无法对这些项目进行合并，因为它不知道它们的共享历史记录。对于Subversion来说，这些包含完全不同的文件。他们可能有相同的名称和相似的内容，但它们是不同的文件。合并只是无效。

• 那么，您是否以这种方式创建了分支？如果是这样，你做得很好。

• 第二个问题：你是否将你的功能分支直接关闭后备箱？这不是必需条件，但如果要合并的分支不在要合并的分支中，则合并会更清晰。

• 第三个问题：您的功能分支是干净的结帐。 svn status --no-ignore告诉你什么？你已经完成了svn update吗？确保您的工作副本清洁可为您节省很多麻烦。事实上，如果可能的话，我建议开发人员只做一次全新的结帐。

• 是你的服务器Subversion版本和你的客户端Subversion 1.6或更高版本。合并跟踪在版本1.5中增加了，但是这是一种惹人注目的事情。客户端和服务器都应该至少为1.6版本。 （目前的版本是1.8，版本1.9几乎已经准备好发布，所以1.6版本相当老旧）。

如果所有这些都是真的，合并应该非常简单。你检查出功能分支。然后，您将中继合并到功能分支中。

$ svn co $REPO/branches/feature 
$ cd feature 
$ svn merge $REPO/trunk 

颠覆合并通常是三方面的事情。您将中继线上的内容与功能分支上的内容进行了比较，和这两个版本的最后一个共同祖先看起来是什么样子。通过在分支发生之前查看原始文件，Subversion可以知道发生了哪些分支，以及它是否应该被视为合并的一部分。

事情在Subversion合并中有一些技巧，因为还检查了目录更改。

在你的情况下，我能想象这样的事情：

• 在原来的最后的共同祖先目录，该文件在那里。
• 在主干中，文件已被删除。
• 也有人从功能分支删除，但随后加回。

现在，Subversion会合并。最后一个共同的祖先拥有该文件。 Subversion查看树干，并看到该文件已被删除。 Subversion查看分支，并看到该文件已被添加。

所以，Subversion看到了冲突。自从最后一个共同的祖先以来，它被添加到特征分支上，但它也被从主干中删除。它应该做什么？它不能简单地删除该文件，因为它已添加到功能分支中。由于主干和特征分支发生了变化，因此发生了冲突。

如果您的工作副本中碰巧有一个不在Subversion中的文件，也会发生这种情况。 （就像数据文件一样），并且像这样的文件在主干上被删除。 Subversion想要删除文件，但不能。这就是为什么开始清理你正在合并的分支是非常重要的。

可能还有其他原因，你也得到了这个。这很难说。在功能分支上进行干净的结帐。确保svn status -no-ignore什么都不返回。确保您的工作副本完全保持最新状态。做一个svn up就可以了。

然后，如果您收到错误消息，请提供完整的错误消息。检查你的箱子，看看它的样子。也针对您的特性分支的工作副本运行以下两个命令：

$ svn mergeinfo --show-revs eligible $REPO/trunk 
$ svn mergeinfo --show-revs merged $REPO/trunk 

首先会告诉你，有资格被合并主干的修订。第二个将显示以前合并的版本。

然后，查看这些更改的日志，看看是否可以看到任何问题。有时我会在树干和分支上看到bug修复。这是两个单独的版本，但修复了相同的问题，因此修复此错误的主干版本不应合并到分支中。您可以执行svn merge --record-only -c $rev将这些修订合并到您的功能分支中，因此Subversion不会再尝试合并它们。