Welcome to MSDN Blogs Sign in | Join | Help

Why TFS labels aren't like SourceSafe labels

I'm keeping my eye out for reasonable "short" blog topics as all of mine seem to be pretty long :)  There was a question today on one of our internal aliases about why labels in TFS don't show up in the history display the way they do in SourceSafe.  The originator was under the impression that labels were not available in the UI.  Here's my response:

You can get labels in the UI although not in history.  When in the Source Control Explorer, you can use File -> Source Control -> Labels -> Find Label.

The difference with SourceSafe is that they are not included in the history.  There’s a good reason for this.  Labels in SourceSafe were always “point in time” labels.  You generally labeled some tree at some point in time and that implied a label of all of the contents of the tree at the same point in time.  In this respect it is reasonable to display labels in time sequence with history.  Everything before it in the list is in the label and everything after it is not.  This works for a significant percentage of label uses (and is a convenient way to think of them) but not all.

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.

I’m not comfortable that we’ve made this discoverable enough or done enough to enable exploring and manipulating labels yet but that’s a basic explanation why we can’t just do what SourceSafe does.  Expect in future versions to see us improve upon the user experience around these.

Published Friday, November 18, 2005 9:45 AM by bharry

Comment Notification

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

Subscribe to this post's comments using RSS

Comments

# Upgrading to the Team Foundation Server Release Candidate

Wednesday, February 08, 2006 10:15 AM by Erwyn van der Meer
Yesterday the Release Candidate for Team Foundation Server was released on MSDN Subscriber downloads. Upgrading my Beta 3 Refresh installation of Team Foundation Server to the Release Candidate went very smooth.

# Quickie: bharry on VBLs and branching

Saturday, April 22, 2006 9:36 AM by Stuart Celarier
A couple of posts by Brian Harry (bharry) from November 2005 about virtual build labs and branching on the TFS project...

# Finding the changes between two labels in TFS version control

Monday, August 28, 2006 8:19 AM by Buck Hodges
Carl Daniel (code) and Robert Downey (code) each wrote and posted code to show the changesets between...

# Label in Team Foundation Server

Wednesday, August 30, 2006 7:40 AM by jankyBlog

# re: Why TFS labels aren't like SourceSafe labels

Thursday, October 19, 2006 3:59 PM by Randy Astle

A somewhat frustrating issue is that the Find Label dialog only allows you to select team projects and not subfolders under a specific team project -- where the labels are in practice actually applied.

At a minimum, it would be nice to have a label history window (if label history isn't displayed in the changeset history window.

# re: Why TFS labels aren't like SourceSafe labels

Friday, October 20, 2006 9:39 AM by bharry

I agree with you.  We are working on a design for a more capable history window that includes label history and the ability to scope it to files and folders.

Brian

# re: Why TFS labels aren't like SourceSafe labels

Monday, November 20, 2006 11:53 PM by Ben Graham

Any idea on an ETA for when this may be improved?  After a conversion from SS to TFS, our version control history is practically unusable.  We have about 180 sub projects (drivers) all with labels like  (V2.35.005)  This makes the find tool useless, as there is no way to search for a particular drivers release.  We will work around this issue by running a script to rename all our labels with the driver name prefix, then converting the SS database again.  Still it would have been nice to search at the subfolder level.

# re: Why TFS labels aren't like SourceSafe labels

Tuesday, November 21, 2006 9:36 AM by bharry

I don't have a timeframe for you at this point but it's definitely something we plan to improve.

# re: Why TFS labels aren't like SourceSafe labels

Wednesday, March 28, 2007 1:30 PM by Mark Taylor

If a label specifies the version of each file, how difficult would it be to add a column to the file history which includes a comma delimited list of labels that reference the specific file version?

This would help a lot in spotting the changes that have been made between two labels.

Mark

# re: Why TFS labels aren't like SourceSafe labels

Wednesday, March 28, 2007 1:56 PM by bharry

It's not hard to do it in file history at all.  It becomes a lot harder to do it on folder histories in any meaningful way because, for a collection of things, labels aren't associated with a specific point in time but rather potentially different points in time for each thing in the folder.

Brian

# re: Why TFS labels aren't like SourceSafe labels

Tuesday, April 24, 2007 12:46 PM by tk70

Any ideas on when MS will take a non-developer approach to this discipline?  

A developer approach isolates the rest of the disciplines in the SDLC and cause significant limitations for an appropriate end-to-end SDLC solution.

I have over 15 years experience and have never seen a developer-based implementation work well.  I was very excited when MS announced they would be moving away for VSS, but was greatly disappointed with the new set of tools as it demonstrates that MS is still way off target for this industry.

-tk70

# re: Why TFS labels aren't like SourceSafe labels

Tuesday, April 24, 2007 1:32 PM by bharry

Could you me more specific?  What do mean by a non-developer based approach to this discipline?

Brian

# re: Why TFS labels aren't like SourceSafe labels

Tuesday, April 24, 2007 2:02 PM by tk70

CM/SCM is a non-developer discipline with its own set of requirements that version control tools need to account for.

VSS got a pass because it was not created as an enterprise solution---as one of its original creators you could agree or disagree with that statement.

TF needs to have solid involvment from the CM/SCM community to ensure that it and other SDLC-based tools are created properly.  It should be developed based on the right set of requirements, not just what will make developers happy.

Take DirectX for example.  MS created it with little input from the game community originally.  Initially, not a very many game programmers liked it.  After MS involved the game community, DX got A LOT better and is now the standard.  Yes, I can make this claim as I am also heavily involved in that industry.

As a big fan of MS, I would like nothing more than to see the company succeed in this market space, but the current path tells me that MS will have a hard time making the desired impact and while MS plays catch up other established companies are getting better.

Just my thoughts and trying to provide valuable feedback.  This is not a bash post, so please don't take it that way.

Thanks for listening....

# re: Why TFS labels aren't like SourceSafe labels

Tuesday, May 01, 2007 2:50 PM by bharry

I appreciate that and would love to discuss with you ideas you have for how we could evolve TFS to better suit the community you have in mind.  What do you think we should do differently?

Brian

# re: Why TFS labels aren't like SourceSafe labels

Thursday, May 03, 2007 5:35 PM by tk70

The CM/SCM discipline should be involved in SDLC from start-to-finish---although it never seems to happen that way :)

While we don't tell BAs, Architects, PMs, etc. how to do their jobs, we do maintain the artifacts that are generated from each discipline and thus, install, configure, integrate (in some cases), and maintain the tools used by those disciplines.

So, it would be nice to have a complete suite of tools that are tightly integrated---a good example is Office.  Each tool can work in standalone, but is also very aware of the other tools in the suite.

Right now, the general impression of the MS offering is a bunch of existing tools trying to work together.  But they were never really built to play together in the way they are offered today.

I would love to see MS offer a suite like IBM Rational's, but with A LOT less overhead.  They have shown how a tightly integrated suite can be successful, but it is way too bloated and requires a dedicated team to support it.  MS has the power and backing to offer the same type of suite, but has the opportunity to make it slick and easy to use---all without having to spend a ton of money on separate hardware architectures to support it.

Now in offering a tightly integrated suite, MS could give CM/SCM the power we always desire---a shell environment with a very powerful command system.  The ability to write scripts across all tools in the suite for better streamlining of workflows/processes.  No need for Python, Perl, etc.  We could leverage the sheer power of .Net and make some very sweet things happen.  No more Crystal Reports, we could leverage Reporting Server's full power.

This is surface level stuff, but hopefully it is a starting point.  I know TF/TFS is going there because I did take the time to really review your blog.  But I feel MS is just reinventing the wheel with little flare to make a company tank their current investment. I have kept IBM Rational in many, many customer sites once I showed what it could do when you know what you're doing.  I'm just waiting for the same opportunity to standup and show what MS is capable of doing.  Let's face it IBM couldn't do it that's why they bought Rational.  But MS has proven that when it listens, it evolves entire industries (and the world).

tk70

# re: Why TFS labels aren't like SourceSafe labels

Friday, May 04, 2007 7:57 AM by bharry

Thanks for the feedback.  A couple of thoughts.

The VSTS tool sets aren't a bunch of cobbled together tools.  Much of VSTS was written from the ground up to be an integrated suite.  In a few places we have used internal technology that has been around a while.

I agree that a powerful, easy to use and integrated suite is what the world needs and what we are trying to provide.  We only have V1 in the market right now.  Our Orcas release will move us forward and our Rosario release should be a big step.

I agree scripting is a huge component of SCM.  That is why we provide a full function command line for basic scripting.  We also expose all of our APIs in a .NET object model for rich control.  We expose exactly the set of APIs we use to build our tools.  We also expose web services to support X-plat and integration with other systems.  We are currently investing in PowerShell support to provide yet another rich way to script that falls between the command line and the .NET object model.

Again, thanks for the feedback.  I think we are on the same page.

Brian

# re: Why TFS labels aren't like SourceSafe labels

Friday, May 04, 2007 10:26 AM by tk70

Brian that is EXCELLENT NEWS and thanks for the insight!  I have made a note to follow Orcas and Rosario closely.

Please let me know the best place to track these future releases as I would like to get a jump start on them so when they hit the market I am already up to speed on them and can provide instant value to my customers.

tk70

# re: Why TFS labels aren't like SourceSafe labels

Friday, May 04, 2007 10:33 AM by tk70

By tracking the future releases I mean more of a technical/programmer site so I can sharpen my skills and stay aware of changes in future releases.

tk70

# re: Why TFS labels aren't like SourceSafe labels

Friday, May 04, 2007 10:36 AM by bharry

My blog is a good place to watch.  I announce all of these things and provide color commentary about what to expect from TFS and VSTS, in general.

Brian

# re: Why TFS labels aren't like SourceSafe labels

Friday, May 04, 2007 10:41 AM by tk70

Brian, my apologies and I promise this is my last question.  Is there any reason why the industry (and maybe MS---not sure) always focuses on what these tools do for developers and development?

I mean the tools support ALM/SDLC, but I never hear anything about how they help BAs, PMs, CMs/SCMs, etc.  It's always about how they help developers.  Maybe that's why my perception stated in the intial post is (unintentionally) skewed.

Thanks,

tk70

# re: Why TFS labels aren't like SourceSafe labels

Friday, May 04, 2007 11:03 AM by bharry

One place to track is: http://msdn2.microsoft.com/en-us/vstudio/aa700830.aspx

In the left hand margin you'll find a link to specs for upcoming features and links to downloads of Betas, CTPs, etc.

I can't say for sure why the industry has focused primarily on devs.  I'll speculate that it's because, historically, that's where most of the money has been.  For team system, our value proposition is that the whole is greater than the sum of the parts and that we deliver the most value by including everyone in the application lifecycle.

Also, read the VSTS roadmap here: http://msdn2.microsoft.com/en-us/teamsystem/bb407307.aspx

You'll find things like:

* Project management across multiple projects for proactively load balancing resources according to business priorities

* Full traceability (inc. hierarchical work items) to track project deliverables against business requirements and the ability to conduct rapid impact analysis of proposed changes

where we talk about the kinds of things we want to do for project managers and business analysts.

Lastly, keep an eye on: http://msdn2.microsoft.com/en-us/teamsystem/default.aspx

This is the main Team System portal.

Brian

# re: Why TFS labels aren't like SourceSafe labels

Friday, May 04, 2007 5:36 PM by tk70

Brian: THANKS again!!!  I realize this was probably not the best place for these discussions and I also realize just how busy you are, so I really appreciate you taking time out to chat with me.

I look forward to future discussions with you and the others in a more appropriate forum :)

tk70

# file history

Thursday, September 13, 2007 1:19 AM by Carlo Bos

Will you please give me a date when the label information will be included in the file history?

This is a very important feature, esp. when I'm trying to figure out if a particular file was labled correctly!

# re: Why TFS labels aren't like SourceSafe labels

Saturday, September 15, 2007 2:46 PM by bharry

I don't have a concrete date.  We are currently building that feature (along with other history improvements) for our Rosario release.  I'm going to look into the possibility of releasing it as a PowerTool before hand.

Until then, check out TFS Sidekicks at http://www.attrice.info/cm/tfs/index.htm and see if it has something that will help you.

Brian

# re: Why TFS labels aren't like SourceSafe labels

Friday, October 26, 2007 10:58 AM by Joe

I found this discussion very interesting and know where tk70 is coming from. One slight correction - MS was not the original creator of what is VSS. It was developed by a company called OneTree and was on the market a few years in the early 90's when MS acquired them.

Also, the very idea of replacing files in a label contradicts good SDLC discipline. I think the best purpose a label serves is a baseline. Mechanisms that can change identified baselines defeat the purpose of having a baseline. I believe even VSS had the ability to extract a file from a label and replace it with another version. I am guessing this ability only existed because many companies use automated build/compile scripts and require the label intact to kick off the process. If there was a problem with any one file, they might just replace the one file in the label and rebuild, rather than make a whole new label with different version number. For work internal to development, this might be OK. But when releasing to a major test bed or production, this is not a good practice.

# Labels and branches in Team Foundation Server « The Microserf

Wednesday, December 05, 2007 4:28 AM by Labels and branches in Team Foundation Server « The Microserf

# Website Scripts » bharry’s WebLog : Why TFS labels aren’t like SourceSafe labels

# Labels, ChangeSets and Continuous Integration

Saturday, April 26, 2008 10:43 PM by Mat Steeples

We make use of continuous integration on the project I'm on at the moment. A summary of Continuous

Leave a Comment

(required) 
required 
(required) 
 
Page view tracker