首先是问题，然后是一些背景。
我们使用Visual Studio 2008，C＃3.0和.NET 3.5以及TFS 2008作为我们的VCS。
如果我对TFS数据库执行此命令，则显示有关合并提交的信息：
tf changeset 13469 /noprompt
我得到这样的输出（编辑）：
Changeset: 13469 User: Lasse Date: 12. november 2010 14:06:06 Comment: Some text here. Items: merge, edit $/path/to/target/filename.txt ... more merged files ... some blurb about reviewer texts, etc. nothing important/useful here
这是从同一数据库中的不同路径合并而来的，但此信息在此处不可用。
例如，如果我从$/path/to/main/合并到$/path/to/branch/，则合并变更集中的主项目路径不可用。 （请注意，请不要说我合并错误的方式，在这种情况下无所谓，所以我只是简单了。）
所以，问题是这样的：有什么方法可以找出变更集的合并位置？它来自哪个分支？ ... 和它改变了它起源于那个分支（如13468？13462？13453？...）
背景
到目前为止，我们还没有使用太多的分支和合并，除了“标记”版本之类的简单内容。
从现在开始，我们正在考虑使用更活跃的分支，但这会带来挑战。
假设我打开我们的错误跟踪器，获取最顶层的错误，修复它并检查它。这是在一个分支中完成的，假设这是主分支。
现在，在某些时候，测试人员将验证我们将要发布的修补程序是否已修复此错误，因此他打开了我们的产品并希望在启动之前验证错误修复程序实际上已经进入此状态建立。
当我们不使用分支时，我们只需获取最终修复案例的提交的变更集编号，并将其输入到案例本身中。此外，我们的产品使用与变更集相同的构建号（版本号的第4部分）构建，变更集是构建构建的最新变更集。
通过这种方式，测试人员可以简单地查看案例，版本号并轻松推断构建是否具有该变更集。如果版本号中的变更集编号等于或高于案例中的变更集编号，则变更集是该构建的一部分。
使用分支机构，这不起作用。如果我在主分支上提交变更集X，但忘记合并，则测试人员不能简单地说“如果我运行版本X或更高版本，我会再修复”。
请注意，我们没有使用TFS工作项，因此没有简单的内置方法来链接提交和案例。
我询问TFS历史输出的原因是我假设如果我能看到变更集13469真的来自另一个分支，并且对应于那里的变更集13462，并且程序员已经注意到案例13462，我可以说“13462现在是构建的一部分，因为它已合并到右分支，变为13469，构建输出的版本为13470.”
换句话说，我可以构建一个工具，作为构建的一部分查看数据库的历史记录并抓取所有必要的信息并将其存储在数据库中，这样我就可以把案例放在我们准备好的测试列表并与运行测试程序的可执行文件的版本号进行比较，并列出所有准备测试和部分构建的案例。
所以我的问题是这样的：有没有人对我们如何解决这个问题有任何暗示？也许我们头脑发热，需要被告知正确的方法，所以如果你有任何好的想法，请告诉我。
答案 0 :(得分：0)
我听到并感觉到你在这里感叹，因为我们遇到了同样的限制。有了TFS 2008，就没有简单的方法来查看历史记录。借助TFS 2010和分支可视化工具，它变得更加容易。
如果这是您真正需要的，您可以使用TFS API自行编写。您将不得不回过头来查看文件的各种更改集。编码相对简单：
之前我已手动完成此操作，但您可以使用C＃代码执行此操作，或者编写PowerShell脚本来执行此操作。