jesfer

Interesting fact regarding work item link filters when working with the Process Editor to create a new process template:

"Include all" does not equal "Include" + selecting all link types.

• "Include all": link types from all installed process templates will be shown to the users.
• "Include" + check all boxes: Only the links types in the current process template will be shown to the user.

In my experience, "Include all" is never a good option for a work item link filter. It will only serve to confuse users and break reports. But when working with the Process Editor "Include" restricts your selection of link types to only include those specified in you process template. If you want to use link types from your template and some of the system defined link types (like parent/child) you will have to edit the XML markup manually.

Brian Harry recently blogged about a cool new feature in the next version of TFS Power Tools (no date yet). Backing up and Restoring your TFS Server is the most exhaustive post and makes for some interesting readin while Backing up your TFS Server with Sharepoint and Reporting more or less just states that you can backup the Sharepoint and Reporting parts of TFS as well.

Now, lets hope they add a tool for restoring the backups as well

I recently stumbled across a interesting case using TFS 2010 where you could end up unintentionally setting a field on a work item that is not supposed to use the field at all. This is probably best explaned with a simple example.

Lets say you team project is based on the MSF for Agile v5 template. You want to modify the Task WIT so that the LinkControl in the Links tab includes a column for severity. This way, whenever a Task is linked to a Bug you will know the severity of the bug without opening it up. Perfect! Lets do it!

I'll skip the details of how to do this, the interesting part is that even though Task does not use the field Severity you will need to add it to the Task WIT in order to show it as a column in the LinkContol. Name, Field type and Ref name must be identical to what is used in the Bug WIT. And this is where you might make a small but potentially very annoying mistake. If you also copy the rules of this field from the Bug WIT (easily done if you copy/paste between XML-files or if you are just very thorough and decide to specify the field exactly as it is on the Bug WIT) all your Tasks will from now on be asigned the severity level "3 - medium".

And why is this bad? Well, you'll probably not notice it for some time. If you are lucky you wont ever notice it and if so, good for you! But chances are that sooner or later someone will get a very wierd result from a work item query or report. Lets say you have a report that counts the number of bugs of each severity level. Depending on the laziness of the person who designed the report, it might not check the work item type because only bugs used to have a severity level... and now this report is telling you that the number of bugs of severity level "3 - medium" is increasing at an alarming rate!

Good news is this that the mistake is fairly easy to solve. Remove all rules for the severity field on the Task WIT, create a query to return all tasks with severity "3 - medium", export to excel, remove severity value from all tasks and publish the changes back to TFS. Done! Unless your report keeps track of history as well...

Recently one of my clients (who uses TFS 2008) encountered the TF14083 warning when merging two branches. This is the warning message:

The item '{0}' has a pending merge from the current merge operation, please resolve and check in the current merge and merge again to pick up this change.

In most cases this is nothing to worry about, all you need to do is just what it says in the message. Resolve, check in and merge again.
But a cautious user might start to think along the lines of "so,what happens if the second merge fails? I've already checked in the first part of the merge!". The simple answer would be that you do a rollback to the previous changeset using TFS 2008 Power Tools.
However, in TFS 2008 the rollback will only rollback the actual changes but the merge history will not be affected and this will cause trouble when you try to redo the merge operation as TFS believes the two branches have already been merged. You can probably solve this dilemma by doing the merge using TFS command line tool and use the /force option but by now most people are thinking something along the lines of "this is stupid, TFS should be able to handle all this".

And if you move to TFS 2010 it can! Not only has one of the main reasons for the error above been fixed, but rollback is now part of the standard TFS command line tools and has an option for keeping merge history or not. There, another good reason why you should move to TFS 2010!  

I found some more info on TFS 2010 and the "Basic" version on bharry's WebLog.

Lot's of nice pictures there but I'll skip right to the listed features of TFS 2010 Basic:
All of this gives you a development system with Version Control, Bug tracking and build automation (making continuous integration a snap!).  What it lacks from Standard TFS is Sharepoint and Reporting capabilities.  The great thing though is that TFS "Basic” IS TFS so as your needs grow you can reconfigure it to add more capabilities.

I'm guessing this will quickly become the most common setup. SourceSafe on steroids... while TFS Standard/Advanced will be SourceSafe on sci-fi steroids :)  

Apparently support for SourceSafe is set to end in mid-2011. SourceSafe users need not worry, MS has you covered. With TFS 2010 there will be a "Basic" installation option which will allow you to installa TFS (or at least a part of it) on client OSes. Just like SourceSafe. Further more, the Basic version is supposed to be cheaper than the full TFS license.

Now, the only question is what features of TFS will be included in this Basic installation? My guess is source control only. Which is more than enough reason to move from SourceSafe to TFS Basic asap in my opinion. 

So, here is the short review of TFS Windows Shell Extensions in Visual Studio Team System 2008 Team Foundation Server Power Tools.

Me and a couple of colleagues installed it... and it is actually quite nice. Now that I have it installed I dont think I want to work without it  You get all the basic TFS source control related actions in the explorer window, no more, no less. The name is still a few letters too long for my liking

One of my colleagues ran into some trouble with TFS Windows Shell Extensions though. The icon overlays in explorer did not show up properly. Turns out there was a "simple" explanation...

"Windows Shell has a hard limit of 15 registered Icon Overlays and reserves 4 for its own use. If you do not see your TFS controlled files and folders displayed with these overlays but the context menus are displaying correctly you may have run into this limit. The only workaround is to uninstall one of the applications that is using the available slots or disabling its shell integration."

No big deal, as long as you know which application to uninstall...

Lately I've had a few TFS users complain to me that the TFS client (aka Team Explorer+Visual Studio) lacks the explorer integration you get with TortoiseSVN. Now, I've never felt the need for this feature but decided to do some research. And guess what? You CAN get explorer integration with TFS! In several different ways!

• Visual Studio Team System 2008 Team Foundation Server Power Tools
• Dubbelbock TFS
• SvnBridge
• LizardTF

I have not tried any of them (yet) but I'd recommend the power tools... mainly because it is Microsoft and they'll eventually steamroll the competition (except maybe SvnBridge). Just pay attention to this small but important part of the "instructions" on the download page:

"Please note that the TFS Windows Shell Extensions are not installed by default. Choose Custom when prompted at installation to add the tool to the installed components."

If I'm not too busy I'll write up a short review of the TFS Windows Shell Extension in Visual Studio Team System 2008 Team Foundation Server Power Tools. Jeez... Microsoft, you relly need a shorter name for these tools!

My colleague Torkel Ödegaard just released CodeSaga, a free source code repository analyser for TFS and Subversion. Not only does it have some really nice and useful features (with more coming) but it looks real good too! Nice work Torkel!

I just found a wonderful collection of tools called TFS Sidekicks. I'd recommend it to all TFS administrators who dont want to mess around with command line tools, which is just sooo last century  

The program is actually five or so different TFS sidekick tools that have been combined into a single tool. Not that I've checked but I dare say that it offers no unique functionality but you get a lot of useful stuff in one place and a nice GUI.