我们有一个名为“Main”的分支。 2012年7月，我为这个项目的下一个版本创建了一个名为“第3阶段”的新分支。从那时起，我们一直在努力解决这个问题，但有时会对Main进行一些其他更改。
今年5月，我们进行了从Main到第3阶段的合并，其中包括一些变更，这一切都很好。
从那时到现在，我们将我们的TFS服务器从2008升级到2012更新3.（我没有参与“升级”，但我相信它是在新服务器上安装，具有某种备份/恢复功能数据。）我们对此有任何其他问题。
上周我尝试执行从Main到Phase 3的另一次合并。我选择了“选择的变更集”，因为我们在第3阶段分支中进行了大量的返工，因此合并变更非常困难 - 所以我想做他们一点一滴。
然而，我很惊讶地看到Visual Studio试图合并2011年7月之后的变化 - 这是分支制作之前的好年份（实际上是对我们项目的这一部分进行的第一次更改。）
奇怪的是，如果我查看第3阶段解决方案的历史记录，我可以扩展它并查看所有这些变化。所以TFS似乎知道他们已经应用了。
我尝试合并一些早期的更改，看看会发生什么。它包含的唯一更改是与已重命名或删除的项目有关。例如，我们已经重命名了我们的解决方案，因此TFS希望分支并合并SLN的副本和旧名称。或者我们有一些图像随后在两个分支中被删除，但在此新合并时却没有。
所以我支持这一点并试图在今年5月份之前整合所有内容 - 也就是在我们上一次合并之前。这带来了大量的变化 - 各种各样的事情，包括定期合并/编辑类型的变化。所以我也支持了这一点！
我们已经从第3阶段创建了另一个分支。我已经能够在两个分支之间合并了。我认为它是在TFS升级前一周创建的。但它没有遇到这个问题。
我们还有其他分支机构来自Main。这些问题正在经历TFS想要应用已经发生的变化的问题。
我正在使用VS2012更新3进行合并。我也试过VS2010，以防万一，但也是如此。同事也试过并确认了相同的症状。
我认为我们的第3阶段与主要版本之间存在巨大差异，以至于合并任何内容都非常困难。
有谁知道我怎么能最好地解决这个问题？我有点担心做一些我可能后悔的事情！
答案 0 :(得分：4)
从TFS 2008升级到TFS 2010时遇到类似的问题。问题可能是部分合并的变更集。即变更集中的一些文件已合并，有些则没有。或者它可能是分支移动/重命名的情况。有关分支重命名可能导致此问题的详细信息，请参阅答案here
在TFS 2008中，如果您尝试合并，则取消选中待更改列表中的文件。 TFS假设您不想再次合并该文件，并且在后续合并中您不会看到这些文件。
在TFS 2010或更高版本中，行为会发生变化。如果取消选中待处理更改中的文件，则在下一次合并时，TFS将尝试再次合并这些文件。我认为TFS 201x具有正确的行为，但MS没有强调行为的变化。
要检查是否是这种情况，请从命令行运行以下命令
tf merge $/tp/main $/tp/phase3 /recursive /candidate
/candidate开关告诉TFS在不执行合并的情况下为您提供要合并的变更集列表。如果您在列表中看到其旁边有*的任何更改集，则会部分合并这些更改集。
要修复它，您有2个选择。
合并文件并解决冲突，可能值得根据变更集合并更改集，而不是尝试一次完成所有操作。这可能会有点痛苦，但一旦完成它就完成了。
如果您确信phase 3分支正确，则可以使用命令提示符进行合并。如果您使用tf merge $/tp/main $/tp/phase3 /version:c123~c456 /recursive /discard，其中c123表示您要忽略的最旧变更集，c456表示您要忽略的最新变更集。 /discard开关告诉TFS更新合并历史记录，以便它认为合并已完成，但它实际上不会执行合并。这应该从您的候选人列表中删除部分合并的变更集
如果您选择选项2，那么您应该进行一些分析以确保您确实不想采用部分合并的变更集。
答案 1 :(得分：0)
如果你到了合并太难的地步，或者你只是不相信它......那么唯一可行的选择是“用新的变更集来踩它”。 ie - 在TFS之外手动合并，然后提交新的固定变更集。然后，杀死旧分支并重新开始。
不是理想的情况，但您的来源完整性至关重要。希望从一个新的分支开始，将来会阻止这样的问题。