1

我们有一个名为“Main”的分支。2012 年 7 月，我为此项目的下一个版本创建了一个名为“阶段 3”的新分支。从那时起，我们一直在努力解决这个问题，但有时其他一些更改会应用于 Main。

今年 5 月，我们进行了从 Main 到 Phase 3 的合并，并进行了一些更改，这一切都很好。

从那时到现在，我们将我们的 TFS 服务器从 2008 年升级到 2012 年更新 3。（我没有参与“升级”，但我相信它是在新服务器上安装并进行某种数据备份/恢复。 ）我们对此有任何其他问题。

上周我尝试执行另一个从 Main 到 Phase 3 的合并。我选择了“选定的变更集”，因为我们在 Phase 3 分支中进行了大量的返工，因此合并更改非常困难 - 所以我想一点一点地完成它们少量。

然而，令我惊讶的是，Visual Studio 试图从 2011 年 7 月开始合并更改——这是在创建分支之前的好一年（实际上是对我们项目的这一部分所做的第一次更改。）

奇怪的是，如果我查看第 3 阶段解决方案的历史，我可以展开它并查看所有这些变化。所以 TFS 似乎知道他们已经申请了。

我试图合并一些早期的更改，看看会发生什么。它包含的唯一更改与已重命名或删除的项目有关。例如，我们重命名了我们的解决方案，因此 TFS 希望分支并合并 SLN 的副本与旧名称。或者我们有一些图像随后在两个分支中被删除，但不是在这次新合并时。

所以我放弃了这一点，并试图从今年 5 月开始合并所有内容 - 即在我们最后一次合并之前。这带来了大量的变化——各种各样的事情，包括常规的合并/编辑类型变化。所以我也支持了！

我们已经从第 3 阶段创建了另一个分支。我已经能够在两个分支之间合并 OK。我认为它是在 TFS 升级前一周创建的。但它没有遇到问题。

我们还有其他取自 Main 的分支。这些正在经历的问题是 TFS 想要应用它已经做出的更改。

我正在使用 VS2012 update 3 进行合并。为了以防万一，我还尝试了 VS2010，但效果相同。一位同事也尝试过并确认了相同的症状。

我认为我们的第 3 阶段与 main 有很大的不同，以至于合并任何东西都非常困难，我认为这没有帮助。

有谁知道我怎样才能最好地解决这个问题？我有点担心做一些我以后可能会后悔的事情！

4

2 回答 2

4

从 TFS 2008 升级到 TFS 2010 时，我遇到了类似的问题。问题可能是由于部分合并的变更集。即变更集中的一些文件已经被合并，有些还没有。或者它可能是分支移动/重命名情况。有关分支重命名为何会导致此问题的详细信息，请参见此处的答案

在 TFS 2008 中，如果您尝试合并，则未选中待处理更改列表中的文件。TFS 假设您不想再次合并该文件，并且在随后的合并中您将看不到这些文件。

在 TFS 2010 或更高版本中，行为发生了变化。如果您取消选中挂起更改中的文件，则在下一次合并时，TFS 将尝试再次合并这些文件。我认为 TFS 201x 具有正确的行为，但是 MS 没有强调行为变化是一个痛苦。

要检查是否是这种情况，请从命令行运行以下命令

tf merge $/tp/main $/tp/phase3 /recursive /candidate

该/candidate开关告诉 TFS 给你一个它想要合并而不执行合并的变更集列表。如果您在列表中看到*旁边有 的任何变更集，则这些变更集已部分合并。

要修复它，您有 2 个选择。

  1. 合并文件并解决冲突，可能值得在一个变更集的基础上合并，而不是尝试一次全部完成。这可能会有点痛苦，但一旦完成，它就完成了。

  2. 如果您确信phase 3分支是正确的，那么您可以使用命令提示符进行合并。如果您使用tf merge $/tp/main $/tp/phase3 /version:c123~c456 /recursive /discardwherec123表示您要忽略的最旧的变更集，并c456表示您要忽略的最新变更集。该/discard开关告诉 TFS 更新合并历史记录，以便它认为合并已经完成，但它实际上不会执行合并。这应该从您的候选人列表中删除部分合并的变更集

如果您选择选项 2，那么您应该进行一些分析以确保您真的不想采用部分合并的变更集。

于 2013-08-12T21:16:37.200 回答
0

如果您到了合并太困难的地步，或者您只是不信任它..那么唯一实用的选择是“用新的变更集踩在它上面”。即 - 在 TFS 之外手动进行合并，然后提交新的、固定的变更集。然后，杀死旧分支并重新开始。

不是一个理想的情况，但你的源完整性是最重要的。希望从一个新的分支开始可以防止将来出现此类问题。

于 2013-08-12T21:55:30.620 回答