Welcome to MSDN Blogs Sign
in | Join
| Help

Buck Hodges

Team Build (Build Automation) - Version Control - Team Foundation Server -
Team System - Visual Studio North Carolina

This Blog

About

Email

Jul

August 2006

Sep

S

M

T

W

T

F

S

30

31

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

1

2

3

4

5

6

7

8

9

Syndication

RSS 2.0

Atom 1.0

Search

Go

Archives

August 2006
(21)

July 2006
(5)

June 2006
(1)

May 2006
(4)

April 2006
(7)

March 2006
(23)

February 2006
(16)

January 2006
(4)

December 2005
(9)

November 2005
(12)

October 2005
(13)

September 2005
(13)

August 2005
(4)

July 2005
(6)

June 2005
(8)

May 2005
(6)

April 2005
(4)

March 2005
(3)

February 2005
(10)

January 2005
(9)

December 2004
(1)

September 2004
(1)

August 2004
(5)

July 2004
(7)

June 2004
(11)

May 2004
(8)

News

Hatteras Lighthouse

Disclaimer
These postings are provided "AS IS" with no
warranties and confer no rights.

Our
Office
Command Line
Option Summary (tf.exe)
TFS RTM
Upgrade Guide
Team Foundation
FAQ
Team
Build Forum
Version
Control Forum
Visual Studio 2005 Team
System
VSTS Extensibility
Kit
MS Blog
Portal
Team
System Blogs
Code Colorization

Navigation

Home

Photos

Post Categories

C#
(13)

Random
(14)

Source
Control (155)

Team
Build (17)

VS Team
System (164)

Team System General

Rob Caron

Jeff Beehler

Eric Lee

Somasegar

TFS Version Control

Jim Presto

Ed Hintz

Robert Horvick

Michal Malecki

Tan Phan

Kevin Kelly

Chandru Ramakrishnan

Mario Rodriguez

TFS Team Build

Jason Pricket

Jim Lamb

TFS Admin and Ops

James Manning

Chris Rathjen

Adam Singer

Jeff Lucovsky

John Morris

Team Foundation General

Brian Harry

Tim Noonan

Jason Barile

TS Web Load Testing

Ed Glas

Josh Christie

Bill Barnett

Sean Lumley

VSTS Load Test
Team Blog

TFS Work Item Tracking

Naren Datha

Finding the changes between two labels in TFS version control

Carl
Daniel (code) and
Robert Downey (code)
each wrote and posted code to show the changesets between two labels in TFS
version control.  They each took the same basic approach: call
QueryLabels() to get the set of items in each label, find the highest changeset
version for each set of items, and then call QueryHistory() with the range of
versions specified as the two highest changeset versions found.

There's one technical flaw with this approach.  A label in Team
Foundation Server is not a point in time.  In TFS labels are collections of
files, each at a particular version.  Brian Harry wrote about this difference
in a post titled, Why TFS
labels aren't like SourceSafe labels.

In Team Foundation, labels are more powerful.  Instead of being a
single point in time, they are able to have versions of each file in the label
from different points in time.  The canonical scenario is that you label
a build and then find some bugs and want to go back change the versions of a
few of the files (either omitting changes that introduced bugs or adding
changes that fixed bugs).  Now the label does not represent a point in
time, but rather a collection of points in time.  This makes it very hard
to display it in a list mixed with change sets because there is not “correct”
ordering of the list.  As a result we treat the list of changesets and
the list of labels separately.

Another very common approach is creating a label using the versions of files
in a workspace.  A workspace is also a collection of files, each
potentially from a different point in time.  Team Build labels the files in
its workspace as part of the build process.  By doing this Team
Build guarantees that it is labeling what it's building.  Steve St. Jean talks about this in his
post, Why
I Like Labels in TFS Version Control.

By finding the highest changeset in each label to compute the differences,
the label is inherently being represented at a point time, as a changeset is
just a precise point in time with respect to the state of the repository.
As a result, the report produced by these apps won't necessarily be completely
accurate if the label has been changed, such as Brian describes in his example,
or the label was based on the versions in a workspace where not all versions are
from the same point in time.

Computing the actual set of changes between two labels, taking into account
that labels are not points in time, becomes a much more expensive computation
involving computing the history of each item between the two changesets in the
label (and handling adds and deletes).  In fact, the
GenCheckinNotesUpdateWorkItems task in Team Build takes this fully
accurate approach, and it's why that task is so slow (see GenCheckinNotesUpdateWorkItems
task is expensive and Measuring
Performance of Team Build Build Process).  By the way, you can set
SkipPostBuild to true in your TfsBuild.proj (add this line:
<SkipPostBuild>true</SkipPostBuild>) file to prevent that task
from running if you find it too expensive and don't need the changesets and work
items recorded in the build information and the "fixed in field" updated in
those same work items.

So, should you go with the fast approach used by Carl and Robert or take the
slow approach used by Team Build?  The answer depends on whether your
labels are points in time and what level of accuracy you need when determining
what's changed between two labels.  The approach used by Carl and Robert is
completely accurate if your labels are strictly points.  If you need
complete accuracy and your labels are not points in time, you'll need the more
expensive approach.  If you don't need complete accuracy, the fast approach
may give an answer that's "close enough" for what you are doing.

Published Monday, August 28, 2006 8:00 AM by buckh
Filed
Under: Source
Control, VS Team
System, Team
Build

Comment Notification

If you would like to receive an email when updates are made to this post,
please register here

You can also stay up to date using your favorite aggregator by subscribing to
the CommentRss
Feed

Comments

No Comments

What do you think?

Title
(required)*

Name required*

Your URL

Comments
(required)*

Remember Me?