tfsbuild destroy is your friend

Here is what I just got by using this command.

Microsoft (R) TfsBuild Version 10.0.0.0
for Microsoft Visual Studio v10.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Destroy build record for 258141 permanently? (Yes/No/All) all
Destroying 258141... Done
Destroying 1.6.1.0... Done
Destroying 1.6.2.0... Done
Destroying 1.6.3.0... Done
Destroying 1.6.4.0... Done
Destroying 1.6.5.0... Done
Destroying 1.6.6.0... Done
Destroying 1.6.7.0... Done
Destroying 1.6.8.0... Done
Destroying 1.6.9.0... Done
Destroying 1.6.10.0... Done
Destroying 1.6.11.0... Done
Destroying 1.6.12.0... Done
Destroying 1.6.13.0... Done

… …

Why do I need this? It is because all these builds are accidentally generated due to a cyclic automated check-in when I tried to implement an automated version number increment solution based this perfect post.

What exactly is the root cause of this cyclic check-in and build? The short answer can be located from here. A little bit more detailed explanation is that, the gated check-in will shelve all the files first and then do a build. Then if all succeed, a final check-in will be made; however, the automated check-in to update the version files, will in turn trigger another gated check-in, and again and again, cyclically.

Then why all these builds failed? Shouldn’t they all succeed? It is because, the automated version increment check-in will use the tf command to check-in the files and for a gated check-in, it will return 1 which means “failure” instead of 0 as expected.

Hence, a check-in triggered the gated check-in build, which in turn triggers another check-in which triggers another gated check-in build, again and again…

The result would be a huge list of incomplete builds that consume a lot of build numbers that you want to get back. In this case, tfsbuild destroy would be your best friend.

Till next time,