在构建代理上成功进行门控签入后，如何正确协调 TFS 搁置集? [英] How to reconcile TFS shelveset correctly after a successful gated check-in on the build agent?

问题描述

以下是我们用于成功登记的门控登记流程的简化版本:

Here is the simplified version of our gated check-in flow for a successful check-in:

1. 应用搁置集(构建代理)
2. 构建(构建代理)
3. 从工作区恢复货架集(构建代理)
4. 签入门控更改(控制器上的 CheckInGatedChanges 活动)
5. 获取通过检入门控更改而产生的变更集.(构建代理)

这个流程很成问题.事实上，假设用户 A 提交(提交到门)100 个影响解决方案中所有项目的源文件，然后用户 B 提交仅影响一个项目的 1 个源文件.构建代理上用户 B 的门控签入构建有多大?

This flow is very problematic. Indeed, suppose user A commits (submits to the gate) 100 source files affecting all the projects in the solution and then user B commits just 1 source file affecting just one project. How big would be the gated check-in build for the user B on the build agent?

答案是用户 B 将遭受"与用户 A 相同的构建.

The answer is that user B is going to "suffer" the same build as the user A.

根本原因:我们在检入门控更改之前撤消搁置集，然后再次获取它们，这次是以更改集的形式.这会增加源文件的时间戳，使它们比刚才从相同文件生成的二进制文件更新.

The root cause: we undo the shelveset before checking in the gated changes and then get them again, this time in the form of a changeset. This bumps up the timestamps of the source files, making them newer then the binaries produced a moment ago from the same files.

这是个问题.

我该如何解决?

编辑

如果我不恢复搁置集，而是立即获取相应的变更集会发生什么:

Here what happens if I do not revert the shelveset, but get the respective changeset right away:

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>

注意文件的时间戳.它被撞了.我们一无所获.

Notice the timestamp of the file. It was bumped up. We achieved nothing.

推荐答案

tf get/version:C12345 更新时间戳的原因是它在 2010 年的默认行为.这在 2012 年发生了变化，并且可以配置.

The reason why tf get /version:C12345 updates the time stamp is due to that being the default behavior for it in 2010. This was changed in 2012 and made configurable.

在 Visual Studio 2012/TFS 2012 中添加了一项功能，用于控制获取时的文件时间戳，从那时起阅读 Brian Harry 的帖子:

In Visual Studio 2012/TFS 2012 a feature was added that controls the file timestamp on get, read from Brian Harry's post from way back then:

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

Restore file modification time

When TFS gets files on to your local disk, it always sets the file modification time to the date/time that the get operation happened. There are some work practices where this is problematic. Some practices use the date stamp on the file for incremental deployment or other kinds of change management. SourceSafe had 3 options for setting the time stamp on files:

获取文件的时间(这是默认设置，与 make 和其他类似的构建依赖项跟踪器配合使用效果很好).文件在签入前最后一次编辑时的修改时间.文件签入的日期/时间.TFS 2010 及之前版本仅支持选项 #1.在 TFS 11 中，我们添加了对选项 #3 的支持.它可以在工作空间的基础上设置.我们计划在未来添加对 #2 的支持，但尚未实现.

The time the file is gotten (this was the default and works very well in concert with make and other similar build dependency trackers). The modification time that the file had when it was last edited before checkin. The date/time that the file was checked in. TFS 2010 and before only supported option #1. In TFS 11, we have added support for option #3. It can be set on a workspace by workspace basis. We plan to add support for #2 in the future but haven’t gotten there yet.

^来源

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

As you mention in your other question, you're using tf checkin /shelfset /force, which is where your problem lies. As the answer in your other question explains, that checkin goes directly against the server, the workspace on the server is unaffected and as such is left with the pending changes of unshelving that same shelfset.

tf checkin/force 也非常危险，以防其他开发人员使用旁路门控构建来检查更改.TFS 会假设您知道自己在做什么，并会覆盖这些更改.所以:

tf checkin /force is also very dangerous in case anther developer had used by-pass gated build to check in changes. TFS will assume you know what you're doing and will overwrite these changes. So:

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

1. Developer 1 checks in filaA.txt
2. Build server starts gated checkin
3. Developer 2 checks in fileA.txt and bypasses gated checkin
4. Build server finishes and uses tf checkin /shelfset /force and thus overwrites the changes from developer 2

相反，正常的 TFS 工作流程所做的是检查构建代理工作区上的本地更改.tf checkin $//recursive 并在构建结束时删除shelfset，以防构建和签入成功.

Instead, what the normal TFS workflow does, is check in the local changes on the workspace of the build agent. tf checkin $/ /recursive and it deletes the shelfset at the end of the build, in case of a succesful build and checkin.

这告诉构建服务器签入工作区中的本地更改，它现在知道它具有最新版本，并且不必更新时间戳.下次触发构建时，构建代理将从获取最新信息开始(以确保也获取任何绕过签入)，并且它会知道这些文件已经是最新的.

This tells the build server to check-in the local changes in the workspace, and it will now know that it has the latest version, and won't have to update the time stamp. Next time the build is triggered the build agent will start with a get latest (to ensure that any bypass checkins are also fetched) and it will know these files are already up to date.

所以一般来说，您的工作流程，在代理上，应该是这样的:

So in general your workflow, on the agent, should look like:

1. 如果工作区不存在，请创建工作区和映射
2. 如果有任何未决的更改，撤消它们tf undo $//recursive
3. 执行tf get/recursive/version:T(获取最新)
4. 将您的书架放在代理的工作区
5. 构建代码
6. 签入本地未决更改(tf checkin $//recursive)，不要使用/force
7. 如果所有这些都成功，请删除搁架集

1. If workspace does not exist, create workspace and mappings
2. If there are any pending changes, undo them tf undo $/ /recursive
3. Perform tf get /recursive /version:T (get latest)
4. Unshelve your shelfset to the workspace of the agent
5. Build the code
6. Check in the local pending changes (tf checkin $/ /recursive), don't use /force
7. If all of that's succesful, delete the shelfset

如果有任何失败:

1. 撤消所有挂起的更改以协调工作区
2. 让书架保持原状
3. 构建失败.

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

That way the local workspace will better reflect what's going on and you won't have to perform a tf get /version:c12345 to mess up your dates.

这篇关于在构建代理上成功进行门控签入后，如何正确协调 TFS 搁置集?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！