在成功对构建代理进行登机检入之后，如何正确协调TFS架子集？

Question

这是我们成功进行登机手续的门禁登机流程的简化版本：

1. 应用架子集（构建代理）
2. 构建（构建代理）
3. 从Workspace（构建代理）还原Shelveset
4. 检入门控的更改（控制器上的CheckInGatedChanges活动）
5. 通过检入门控更改获得变更集。 （建立代理）

此流程非常成问题。 确实，假设用户A提交（提交给门）100个影响解决方案中所有项目的源文件，然后用户B仅提交1个影响一个项目的源文件。 在构建代理程序上，用户B的门控登机构建将有多大？

答案是用户B将“承受”与用户A相同的构建。

根本原因：我们先取消架子集，然后再检查门控变更，然后再次以变更集的形式获取它们。 这增加了源文件的时间戳，使其比之前由相同文件生成的二进制文件新。

那是个问题。

我该如何解决？

编辑

如果我不还原架子集而是立即获取相应的变更集，会发生以下情况：

PS D:\tfs\DFGatedCheckInTest2> dir 1.txt


    Directory: D:\tfs\DFGatedCheckInTest2


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---        10/24/2014  10:36 AM         12 1.txt


PS D:\tfs\DFGatedCheckInTest2> tf get /version:C105656
D:\TFS\DFGatedCheckInTest2:
Conflict 1.txt - Unable to perform the get operation because you have a conflicting edit
Automatically resolved conflict: edit: D:\TFS\DFGatedCheckInTest2\1.txt as TakeTheirs
Undoing edit: 1.txt
PS D:\tfs\DFGatedCheckInTest2> dir 1.txt


    Directory: D:\tfs\DFGatedCheckInTest2


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-ar--        10/24/2014  11:42 AM         12 1.txt


PS D:\tfs\DFGatedCheckInTest2>

请注意文件的时间戳。 被撞了。 我们什么也没做。

Answer 1

tf get /version:C12345更新时间戳的原因是由于它是2010年的默认行为。2012年对此进行了更改并使其可配置。

在Visual Studio 2012 / TFS 2012中，添加了一项功能，该功能控制获取时的文件时间戳记，可从Brian Brian的帖子中读取，当时：

恢复文件修改时间

当TFS将文件获取到本地磁盘上时，它将始终将文件修改时间设置为发生get操作的日期/时间。 在某些工作实践中，这是有问题的。 一些实践使用文件上的日期戳进行增量部署或其他类型的变更管理。 SourceSafe具有3个用于设置文件时间戳的选项：

文件获取的时间（这是默认设置，与make和其他类似的构建依赖项跟踪器配合使用时效果很好）。 检入前最后一次编辑文件时的修改时间。 签入文件的日期/时间。TFS 2010和之前仅支持的选项＃1。 在TFS 11中，我们增加了对选项＃3的支持。 可以在每个工作空间的基础上进行设置。 我们计划在将来增加对＃2的支持，但还没有到此为止。

^资源

回到问题根源

正如您在其他问题中提到的那样，您正在使用tf checkin /shelfset /force ，这就是问题所在。 正如您对其他问题的回答所解释的那样，签入直接针对服务器，服务器上的工作区不受影响，因此留下了搁置同一架子集的待定更改。

如果其他开发人员使用旁路门控构建来检入更改，则tf checkin /force检tf checkin /force也非常危险。 TFS将假设您知道自己在做什么，并将覆盖这些更改。 所以：

1. 开发人员1检入filaA.txt
2. 构建服务器开始门控检入
3. 开发人员2检入fileA.txt并绕过门控检入
4. 构建服务器完成并使用tf checkin /shelfset /force ，从而覆盖开发人员2的更改

取而代之的是，正常的TFS工作流程是在构建代理的工作空间中签入本地更改。 tf checkin $/ /recursive ，如果构建和检入成功，它将在构建结束时删除shelfset。

这告诉构建服务器签入工作空间中的本地更改，并且现在它将知道它具有最新版本，并且不必更新时间戳。 下次触发构建时，构建代理将从最新版本开始（以确保也获取了任何旁路签入），并且它将知道这些文件已经是最新的。

因此，通常，在代理上，您的工作流程应如下所示：

1. 如果工作空间不存在，请创建工作空间和映射
2. 如果有任何待处理的更改，请撤消它们tf undo $/ /recursive
3. 执行tf get /recursive /version:T （获取最新）
4. 将您的架子集放到代理的工作区中
5. 建立程式码
6. tf checkin $/ /recursive本地挂起的更改（ tf checkin $/ /recursive ），不要使用/force
7. 如果所有步骤都成功，则删除架子集

如果失败：

1. 撤消所有未完成的更改以协调工作空间
2. 保持架子状态不变
3. 生成失败。

这样，本地工作空间将更好地反映正在发生的事情，而您将不必执行tf get /version:c12345来弄乱您的日期。