testing - How to interpret merge information in TFS log output (or: how can I know which changesets is part of a build?) -
first question, background.
we're using visual studio 2008, c# 3.0 , .net 3.5, , tfs 2008 our vcs.
if execute command against our tfs database, show information merge commit:
tf changeset 13469 /noprompt
i output (redacted):
changeset: 13469 user: lasse date: 12. november 2010 14:06:06 comment: text here. items: merge, edit $/path/to/target/filename.txt ... more merged files ... blurb reviewer texts, etc. nothing important/useful here
this merged different path in same database, information not available here.
for instance, if merged $/path/to/main/
down $/path/to/branch/
, path main project not available in merge changeset. (note, please don't i'm merging wrong way, doesn't matter in case made simple.)
so, question this: there way can find out changeset merged from? branch came from? ... and changeset originated in branch (like 13468? 13462? 13453? ...)
background
we haven't used branching , merging far, except simple stuff "tagging" release.
from on we're looking @ using branching more active, creates challenge.
let's open our bug tracker, take topmost bug, fixes it, , checks in. done in 1 branch, let's master branch.
now, @ point, tester going verify hotfix we're going release has bug fixed, opens our product , wants verify before starts bugfix has gone build.
when didn't use branching, took changeset number of commit fixed case , typed case itself. additionally, our product built build-number (4th part of version number) identical changeset latest changeset became part of build.
this way, tester @ case, version number , deduce if build had changeset or not. if changeset number in version number equal or higher 1 in case, changeset part of build.
with branches, doesn't work. if commit changeset x on master branch, forget merge, tester can't "if run version x or higher, go fix" more.
note we're not using tfs work items, there's no easy built-in way link commits , cases.
the reason asked tfs history output assume if can see changeset 13469 came branch, , corresponds changeset 13462 there, , programmer has noted 13462 on case, can "13462 part of build, because merged right branch, became 13469, , build output has version 13470."
in other words, build tool part of build looked @ history of database , grabbed necessary information , stored in database, take cases on our ready-to-test list , compare against version number of executable tester running, , list cases both ready test , part of build.
so question this: have hints how can solve this? perhaps we're boneheaded , needs told right way this, if got ideas, let me know.
i hear , feel lament here, we've run same limitation. tfs 2008, there's no easy way see history. tfs 2010, , branch visualizer, gets easier.
if need, potentially write using tfs api. have walk way through various changesets files. relatively straightforward code:
- get merge changeset
- get prior merge changeset
- determine merge source first changeset
- get history file between dates of 2 changesets.
i've done manually before, either in c# code, or, alternatively, write powershell script this.
Comments
Post a Comment