首先是问题,然后是背景。
我们使用visual studio 2008、c 3.0和.net3.5以及tfs2008作为我们的风投。
如果我对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?……)
背景
到目前为止,我们还没有使用太多分支和合并,除了像“标记”一个版本这样的简单东西。
从现在开始,我们希望使用分支更加活跃,但这带来了一个挑战。
假设我打开我们的bug跟踪器,找到最上面的bug,修复它,然后签入。这是在一个分支中完成的,假设这是主分支。
现在,在某个时刻,测试人员将验证我们要发布的修补程序是否修复了这个错误,因此他打开了我们的产品,并希望在开始之前验证该修补程序是否已经真正进入了这个版本。
当我们不使用分支时,我们只取最终修复案例的提交的变更集编号,并将其键入案例本身。另外,我们的产品是用一个构建号(版本号的第四部分)构建的,它与变更集是最新的变更集,它变成了构建的一部分。
这样,测试人员就可以简单地查看案例、版本号,并很容易地推断出构建是否具有该变更集。如果版本号中的变更集号等于或高于该版本中的一个,则变更集是该构建的一部分。
有了树枝,就不管用了。如果我在主分支上提交变更集x,但是忘记合并,那么测试人员就不能再简单地说“如果我运行版本x或更高版本,我就执行那个修复”。
注意,我们没有使用tfs工作项,因此没有简单的内置方式来链接提交和案例。
我问TFS历史输出的原因是,我假设如果我能看到变更集13469真的来自另一个分支,并且对应于那里的变更集13462,并且程序员在这个案例中已经注意到13462,我可以说“13462现在是构建的一部分,因为它被合并到右分支,变成13469,生成输出的版本是13470。”
换句话说,我可以构建一个工具,作为构建的一部分,查看数据库的历史,获取所有必要的信息并将其存储在数据库中,这样,我就可以在ready-to-test列表中选择一些案例,并与测试人员正在运行的可执行文件的版本号进行比较,只需列出所有既可以测试又是构建的一部分的案例。
所以我的问题是:是否有人暗示我们如何解决这个问题?也许我们是笨蛋,需要告诉我们正确的方法来做这件事,所以如果你有什么好主意,让我知道。
