0

我使用 TortoiseSVN 在 SVN 中管理源文件。我添加了文件并将它们提交到修订版，随后决定分支。我用我需要的文件进行了分支，并在不打算使用的文件的主干上执行了删除。

现在我正在尝试将分支重新整合到主干。使用乌龟，我已经从主干合并到分支的修订范围，从主干上的删除到头部。这使分支保持最新状态。

现在我切换到主干，并尝试将分支中的修订合并到主干，合并表明新文件被“跳过”或删除我现在已完成的文件。

我在合并到最新的主干时是否遗漏了一些东西？

4

2 回答 2

6

颠覆合并需要一些东西：

共同祖先

你认为这很简单，但这种情况经常发生。我见过开发人员会使用 创建一个分支svn mkdir，签出该分支，将文件从主干复制到该分支，然后执行 asvn add将它们添加回。

尽管分支和主干具有相同的名称和相同的结构，但 Subversion 将它们视为两个完全独立的文件。树干和那个分支之间没有共同的历史。当然，开发者应该已经习惯svn cp了将主干复制到分支。

但是，您可以在较小的块中遇到这样的问题。想象一下，开发人员以正确的方式创建分支。然后发现*.jpg项目中缺少一些文件。开发人员签出分支并添加文件。都照顾好了。现在，开发人员意识到主干上也存在相同的错误。没问题，结帐后备箱添加缺少的*.jpg文件。

当然，*.jpg主干上的文件与分支上​​的文件不同。*.jpgs开发人员应该已经合并了从分支创建的修订到主干。

修订冲突

Subversion 不合并分支：它合并更改。这是一个很难理解的概念，但它赋予了 Subversion 很大的合并能力。

我有一个在修订版 100 上从主干创建的分支。

分支的修订历史

  • 100：创建分支
  • 103：错误修正 2001
  • 110：合并主干到分支
  • 112：做出更多改变

主干的修订历史

  • 102：变化
  • 104：错误修正 2001
  • 111：变化

现在我想将我的分支合并回我的主干。如果我没有指定要使用的修订版，Subversion 会尝试找出我需要合并哪些修订版。我从来没有将我的分支合并到我的主干，所以 Subversion 看到我的分支和主干之间的最后一个共同祖先是修订版 100。然后它看到我需要将更改 103、110 和 112 合并回我的主干。

然而，我分支上的修订版 110 是我已经合并到我的主干的更改！如果我不小心，我会尝试将这些更改合并回我的主干中，从而导致冲突。

Subversion 应该可以处理这个问题，但并不总是那么干净。在运行合并之前，请执行以下命令：

$ svn mergeinfo --showrevs eligible $URL/branches/branch

这将显示 Subversion 想要合并到我的主干的修订。我应该查看该列表并确保这些更改不在我的主干上。

假设我查看了这个列表，发现这个符合条件的列表包含修订版 103、110 和 112。请稍等。修订版 103 修复了 Bug 2001，但这已经在主干上修复了。出于某种原因，还列出了修订版 110，修订版 110 是我的主干到我的分支的合并。我也不希望考虑这个修订。

我需要做的是通知 Subversion 不要考虑这些修订：

$ svn merge --record-only -c 103 -c 110 $URL/branches/branch
$ svn commit -m"Updating merge information to prevent collisions with 103 and 110"

现在，我svn mergeinfo --showrevs eligible再次运行，这两个修订不会列出。我基本上已经通知 Subverison 这两组更改已经在我的后备箱中了。

您始终可以--dry-run在完成之前尝试合并。如果您指定要合并的修订版，Subversion 合并始终有效。当您尝试让 Subversion 自行跟踪合并时，往往会出现问题。它肯定比以前好，但 Subversion 可能会与复杂的环境混淆。我们有一个项目重命名了分支，替换了主干，并在主干和其他两个分支之间进行了合并。（不要问为什么。）。

开发人员无法进行合并，因为他们最终产生了数百个冲突。查看符合条件的修订，我能够清理混乱，并使合并工作。

记住要尽早并经常合并：合并的次数越多，合并就越有可能奏效，并且任何冲突都很容易找到。尽量保持简单的合并活动。如果你在两个不同的分支上修复了一个 bug，你需要通过svn merge --record-only.

不管你做什么。不要恐慌。冲突会发生，如果你知道如何解决它们，你就可以避免合并地狱。

于 2014-10-02T19:51:19.483 回答
0

为了进行重新集成，您需要合并分支到要重新集成的分支后Trunk发生的所有修订。

下面是一个例子：

  • 上一个转速...
  • Rev 20 - ( Trunk ) 提交新文件
  • 修订版 21 -（功能分支）创建功能分支
  • Rev 22 - ( Trunk ) 从Rev 20中删除文件
  • Rev 23 - ( Trunk ) 处理随机文件
  • Rev 24 -（功能分支）处理其他随机文件
  • 修订版 25 -（功能分支）将修订版22和23合并到功能分支中
  • Rev 26 - ( Trunk ) 将功能分支重新集成到 Trunk 中

您会注意到，我们将您的文件删除（Rev 22）作为合并到功能分支（Rev 25）的一部分。

现在这给你带来了一个新问题：

Feature Branch当您合并从Rev 25Trunk开始的更改时，您希望拥有的文件将被删除。这是真实和准确的关于实际发生的事情。您将在这里有几个选择：Trunk

  1. 如果已删除的文件在Rev 24期间Trunk被修改，则在尝试按照Rev 25进行合并时，您将收到 Tree Conflict 。您可以在执行合并时使用本地更改简单地将冲突标记为已解决。Feature Branch
  2. 执行Rev 22的仅记录合并，Feature Branch然后执行任何其他必要的合并Feature Branch（这应该等同于我在 #1 中提到的内容）
  3. Feature Branch按照Rev 25执行合并。合并完成后，您可以查看日志Feature Branch并恢复在Rev 25（合并本身）中所做的更改，通过挑选文件并恢复每个文件来删除您的文件。这些恢复会将文件恢复为新文件，以添加到Feature Branch. 请注意，这些文件在历史记录中与原始文件不同。就 SVN 而言，这些被认为是全新的文件，因此它们不与原始文件共享任何祖先。
于 2014-10-02T15:50:23.957 回答