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

Popular posts from this blog

android - Spacing between the stars of a rating bar? -

html - Instapaper-like algorithm -

c# - How to execute a particular part of code asynchronously in a class -