gpt4 book ai didi

visual-studio - Team Foundation Server - 先前合并的变更集重新出现在合并向导中

转载 作者:行者123 更新时间:2023-12-04 07:27:04 26 4
gpt4 key购买 nike

我们的 SCM 结构如下:

Main
|--Release

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

要合并,我会使用源代码管理资源管理器,右键单击“主要”>“分支和合并”>“合并”。选择“Selected Changesets” 只有一个目标分支(发布)。选择变更集,在本地测试, checkin 到发布。这几个月来一直很好。

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

等效的 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 个小时左右的时间内。

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

我可以使用 tf merge/discard 命令来“让它们消失”,但我想深入了解它发生的原因,出于我自己的好奇,如果没有别的。

TIA

更新:

我选择“丢弃”使用以下命令出现的变更集:
tf merge /discard /recursive [source] [destination] /version:C3~C139

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

不幸的是,如果我跑
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

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

最佳答案

您是对的,“*”表示 changset 3 中的某些文件已合并到“发布”中,而其他文件尚未合并。这通常是由于在合并时取消选中待定更改窗口中的文件所致。

您最近是否从 TFS 2008 升级?升级后我们遇到了同样的情况。在 TFS 2008 中,如果您从合并 checkin 中取消选中文件,TFS 会假设您永远不想合并该文件!获取未检查文件的唯一方法是放到命令行并使用 tf merge /force
在 TFS 2010 中,行为发生了变化,现在如果您执行部分合并,TFS 将始终提醒您在部分合并的变更集中存在未完成的合并候选。

你可以做两件事。

  • 合并变更集(鉴于已经过去的时间长度,您不太可能想要这样做)
  • 使用命令 tf merge /recursive /discard /version:C3~C139 [source] [destination]这将告诉 TFS 您希望它认为它已经完成了合并,即使它没有完成
  • 关于visual-studio - Team Foundation Server - 先前合并的变更集重新出现在合并向导中,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9118265/

    26 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com