Team Foundation Server - 以前合并的变更集重新出现在合并向导中答案

【问题标题】：Team Foundation Server - Previously merged changesets reappear in merge wizardTeam Foundation Server - 以前合并的变更集重新出现在合并向导中
【发布时间】：2012-02-02 18:59:50
【问题描述】：

我们的 SCM 结构如下：

Main
 |--Release

开发人员签入到 main。当我们想要发布时，我们会挑选从 Main 到 Release 的合并变更集，测试并运行我们的部署构建，该构建和部署应用程序并标记发布分支。

要合并，我会使用源代码管理资源管理器，右键单击“主”> 分支和合并> 合并。选择“选定的变更集”只有一个目标分支（发布）。选择变更集，在本地测试，签入到 Release。这几个月来一直很好。

但是，今天一些非常早期的变更集刚刚“出现”在源代码管理合并向导中，位于列表顶部。但奇怪的是，并不是全部。

等效的 CLI 命令是

tf merge /candidate /recursive [source] [destination]

此命令返回以下列表：

   3* Person.One      27/11/2009
  43* Person.Two      21/12/2009
  50* Person.Two      22/12/2009
  54* Person.Two      22/12/2009
  57* Person.Two      22/12/2009
 114* Person.One      12/01/2010
 116* Person.One      13/01/2010
 128* Person.One      15/01/2010
 138* Person.One      19/01/2010
 139* Person.One      19/01/2010
7846  Person.Three    19/01/2012
7847  Person.Three    19/01/2012
7848  Person.Three    19/01/2012
7849  Person.Three    19/01/2012
8030  Person.Four     31/01/2012
8031  Person.Four     31/01/2012
8032  Person.Four     31/01/2012
8045  Person.Five     01/02/2012
8050  Person.Four     01/02/2012
8052  Person.Six      01/02/2012
8053  Person.Six      01/02/2012
8054  Person.Three    01/02/2012
8055  Person.One      01/02/2012
8056  Person.Seven    01/02/2012
8057  Person.Five     01/02/2012
8058  Person.Six      01/02/2012
8059  Person.Five     01/02/2012
8060  Person.Five     01/02/2012
8063  Person.Five     02/02/2012
8068  Person.Five     02/02/2012
8069  Person.Eight    02/02/2012
8070  Person.Five     02/02/2012
8071  Person.Five     02/02/2012
8072  Person.Five     02/02/2012
8073  Person.Three    02/02/2012
8074  Person.Three    02/02/2012
8077  Person.Seven    02/02/2012

唯一的“线索”是星号，我认为这意味着部分合并已经完成。

我完全不知道这怎么会发生。服务器上没有进行任何管理。它发生在过去 6 小时左右。

如果我尝试在我的工作区中进行合并，我不会遇到任何冲突，而且，我不确定如果我签入会发生什么。很明显，两年来文件和结构发生了很大变化！

我可以使用 tf merge /discard 命令“让它们消失”，但我想深入了解为什么会发生这种情况，出于我自己的好奇，如果没有别的原因。 p>

TIA

更新：

我选择“丢弃”使用以下命令出现的变更集：

tf merge /discard /recursive [source] [destination] /version:C3~C139

这导致在我的工作区中选择了一些待处理的更改，我已正式签入。

不幸的是，如果我跑了

tf merge /candidate /recursive [source] [destination]

我现在有更多“等待”合并的历史更改，包括我在第一次尝试中尝试丢弃的更改：

   3* Person.One        27/11/2009
  43* Person.Two        21/12/2009
  50* Person.Two        22/12/2009
  54* Person.Two        22/12/2009
  57* Person.Two        22/12/2009
 114* Person.One        12/01/2010
 116* Person.One        13/01/2010
 128* Person.One        15/01/2010
 138* Person.One        19/01/2010
 139* Person.One        19/01/2010
 140  Person.One        19/01/2010
 141* Person.One        19/01/2010
 142* Person.Two        19/01/2010
 149* Person.Two        20/01/2010
 152* Person.Two        20/01/2010
 160* Person.Two        21/01/2010
 161* Person.Two        21/01/2010
 165* Person.One        21/01/2010
 167* Person.Two        22/01/2010
 173* Person.Two        22/01/2010
 199* Person.Two        27/01/2010
 200* Person.One        27/01/2010
 203* Person.Two        28/01/2010
 204* Person.Two        28/01/2010
 205* Person.Two        28/01/2010
 206* Person.Two        28/01/2010
 208* Person.Two        28/01/2010
 213  Person.Two        28/01/2010
 215* Person.Two        28/01/2010
 235* Person.Two        01/02/2010
 238* Person.Two        02/02/2010
 241* Person.Two        02/02/2010
 259* Person.Two        04/02/2010
 262* Person.Two        04/02/2010
 264  Person.Two        05/02/2010
 296* Person.Two        10/02/2010
 309* Person.Two        11/02/2010
 316* Person.Two        12/02/2010
 317* Person.Two        12/02/2010
 320* Person.Two        12/02/2010
 338* Person.Two        15/02/2010
 353* Person.Two        16/02/2010
 365* Person.Two        18/02/2010
 394* Person.Two        22/02/2010
 399* Person.One        22/02/2010
 400* Person.One        22/02/2010
 401* Person.Two        23/02/2010
 403* Person.Two        23/02/2010
 404* Person.Two        23/02/2010
 405* Person.Two        23/02/2010
 424* Person.One        25/02/2010
 426* Person.Two        26/02/2010
 444* Person.Two        02/03/2010
 445* Person.One        03/03/2010
 461* Person.Two        08/03/2010
 476* Person.One        10/03/2010
 477* Person.One        10/03/2010
 478* Person.One        10/03/2010
 501  Person.One        12/03/2010
 502  Person.One        12/03/2010
 503  Person.One        12/03/2010
 504  Person.One        12/03/2010
 506  Person.One        12/03/2010
 511* Person.One        12/03/2010
 515* Person.One        15/03/2010
 517* Person.Two        15/03/2010
 518* Person.One        15/03/2010
 522  Person.One        16/03/2010
 523  Person.One        16/03/2010
 538  Person.Two        17/03/2010
 539  Person.Two        17/03/2010
 540  Person.Two        17/03/2010
 543  Person.One        17/03/2010
 581* Person.Two        18/03/2010
 582* Person.Two        18/03/2010
 644* Person.Two        26/03/2010
 706* Person.One        30/03/2010
 918* Person.One        13/05/2010
1594* Person.One        15/07/2010
1601* Person.One        16/07/2010
1626* Person.Three      20/07/2010
1627* Person.Three      20/07/2010
6153* Person.One        17/08/2011
7691* Person.Four       11/01/2012
7846  Person.Four       19/01/2012
7847  Person.Four       19/01/2012
7848  Person.Four       19/01/2012
7849  Person.Four       19/01/2012
8030  Person.Five       31/01/2012
8031  Person.Five       31/01/2012
8032  Person.Five       31/01/2012
8050  Person.Five       01/02/2012
8054  Person.Four       01/02/2012
8073  Person.Four       02/02/2012
8074  Person.Four       02/02/2012
8104  Person.Six        03/02/2012
8110  Person.Six        03/02/2012
8112  Person.Seven      03/02/2012
8113* Person.Five       03/02/2012
8114* Person.Five       03/02/2012
8127  Person.Seven      06/02/2012
8128  Person.Seven      06/02/2012
8130  Person.Eight      06/02/2012
8135  Person.One        06/02/2012
8138* Person.Five       06/02/2012
8140  Person.Five       06/02/2012
8142  Person.Five       06/02/2012
8143  Person.Nine       06/02/2012
8144  Person.Nine       06/02/2012
8145  Person.Ten        06/02/2012
8146  Person.Eleven     06/02/2012

我真的不知道是什么导致了这种情况发生。任何建议表示赞赏。

【问题讨论】：

标签： visual-studio visual-studio-2010 tfs

【解决方案1】：

你是对的，“*”表示changset 3中的一些文件已合并到“release”中，而其他文件没有。这通常是由于在合并时取消检查挂起更改窗口中的文件造成的。

您最近是否从 TFS 2008 升级？升级后我们遇到了同样的情况。在 TFS 2008 中，如果您从合并签入中取消选中某个文件，TFS 会假定您永远不想合并该文件！获取未检查文件的唯一方法是放到命令行并使用tf merge /force

在 TFS 2010 中，行为发生了变化，现在如果您进行部分合并，TFS 将始终提醒您在部分合并的变更集中有未完成的合并候选者。

你可以做两件事。

合并变更集（考虑到已经过去的时间长度，您不太可能希望这样做）
使用命令tf merge /recursive /discard /version:C3~C139 [source] [destination] 这将告诉 TFS 你希望它认为它已经完成了合并，即使它还没有完成

【讨论】：

嗨，詹姆斯，非常感谢您的帮助。大约 6 个月前，我们确实从 TFS 2008 进行了升级，但我们确实遇到了一个问题，即我们的构建从一开始就将每个变更集与它们关联起来。我们最终找到了一个补丁来解决这个问题，但不确定它是否相关。同意放弃更改似乎是最好的选择，但请参阅上面的更新。
嗨，杰米，老实说，我没有建议。丢弃物为我们完成了工作。我想您可以尝试丢弃 7691 以内的所有内容（不要使用范围，只使用单个变更集编号），这看起来可能会让您到达可以恢复正常合并的地方。如果有任何较旧的变更集需要合并，那么您需要手动取消选择代码，这不是很好，但希望它能让您摆脱困境
是的，丢弃对我不起作用。我们刚刚从我们的主干中剪切了一个发布分支，现在在合并主干->发布时，合并候选列表中出现了很多“旧”变更集。放弃候选人只会带来更多的候选人 - 这就像九头蛇！这是基本的源代码控制用例……来吧 TFS ！！！（顺便说一句，我们使用的是 TFS 2012）

【解决方案2】：

我们确定此行为的原因是之前删除的文件已在 Main 分支中“复活”，即创建了一个具有相同名称的新文件。

发生这种情况时，之前包含此文件的所有变更集都作为部分变更集重新出现在合并对话框中。

完全合并似乎解决了这个问题。

【讨论】：

我很确定我看到了完全相同的问题。感谢您解决这个问题。

【解决方案3】：

我自己也遇到了一些类似的奇怪行为。我们使用与 OP 类似的方法，但我们也会根据需要对发布分支进行更改。

我通过主版本将旧版本（称为“2.30”）的一些更改合并到新版本（称为“2.31”），当我将主版本的更改合并到 2.31 版本时，我看到了一些多年前合并向导中的变更集 - 其中之一是 2011 年的！

以前从未见过这种行为，并认为也许这个发布分支被莫名其妙地污染了，并且将放弃它并在其位置创建一个新版本。

因此，我将对 2.31 发布分支所做的所有更改合并回主分支并全部签入。在创建新分支以替换 2.31 之前，我想我会再次尝试合并向导（从主分支合并到 2.31) 看看这是否神奇地清除了它并且确实如此。这些旧的变更集都没有再次出现。

很奇怪。

【讨论】：