我们的SCM结构如下：
Main
|--Release
开发人员签入main。当我们想要发布时，我们挑选从Main到Release的合并变更集，测试并运行我们的部署构建，构建和部署应用程序并标记发布分支。
要合并，我会使用Source Control Explorer右击“Main”＆gt;分支和合并＆gt;合并。选择“选定的变更集”只有一个目标分支（发布）。选择更改集，在本地测试，签入发布。这已经好几个月了。
然而，今天一些非常早期的变更集刚刚出现在列表顶部的源代码管理合并向导中。但奇怪的是，不是全部。
等效的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命令'让它们消失'，但我想深入了解为什么它发生了，为了我自己的好奇心，如果没有别的。
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
我真的不知道是什么导致了这种情况发生。任何建议表示赞赏。
答案 0 :(得分：5)
你是对的，“*”表示changset 3中的某些文件已合并为“release”而其他文件未合并。这通常是通过在合并时取消检查挂起更改窗口中的文件来实现的。
您最近是否从TFS 2008升级了？升级后我们遇到了同样的情况。在TFS 2008中，如果您从合并签入中取消选中某个文件，TFS会认为您从未希望合并该文件！获取未经检查的文件的唯一方法是删除命令行并使用tf merge /force
在TFS 2010中，行为已更改，现在如果进行部分合并，TFS将始终提醒您在部分合并的变更集中存在未完成的合并候选项。
你可以做两件事。
tf merge /recursive /discard /version:C3~C139 [source] [destination]这将告诉TFS你希望它认为它已完成合并，即使它没有答案 1 :(得分：4)
我们确定这种行为的原因是先前删除的文件已在主分支中“复活”，因为创建了一个具有相同名称的新文件。
发生这种情况时，所有包含此文件的变更集都会在合并对话框中重新显示为部分变更集。
完全合并似乎解决了这个问题。
答案 2 :(得分：0)
我自己也遇到了一些类似的怪异行为。我们使用与OP类似的方法，但我们也根据需要对发布分支进行了更改。
我通过main合并了从旧版本（称为“2.30”）到新版本（称为“2.31”）的一些更改，当我将合并更改从main发布到2.31版本时，我看到了一些多年前合并向导中的变更集 - 其中一个来自2011年！
之前从未见过这种行为，并认为这个版本分支可能会以某种方式神奇地受到污染，并且会放弃它并在其位置创建一个新版本。
因此，我将对2.31版本分支所做的所有更改合并到主服务器并将其全部检入。在创建新分支以替换2.31之前，我想我会再次尝试合并向导（从main合并）到2.31）看看它是否神奇地将它清理干净了。这些旧的变更集都没有出现过。
很奇怪。