Archive for TFS 2010

How to change the local path in TFS 2010?

Have been using TFS 2010 for a while, I consider it a pretty stable and good Development environment for .Net Development. It might be frustrating at time, but once you get comfortable using it, its pretty neat. One of things people get frustrated with is to figure out how to change the local path of your working directory. In TFS they something called Workspaces which is actually your Local working folder. You can have more than one workspace. Within a Workspace you can have the Local Working Folder path mapped to your Source Control Folder. TFS also allows you to edit your Workspace and the Local Folder Paths within it.

How to change the local path in source control explorer?
How to change the local path in team foundation?
How to change the local path in team explorer?
How to change the local path in tfs 2008?
How to change the local path in tfs 2010?

To change your Local Path do this:

Step 1:

In your Visual Studio 2010 Goto File à Source Control à Workspace (Make sure your Visual Studio is connected to your TFS server) Refer to figure below.

Step 2:

Next you should see the following window. Select the Workspace you want to Edit and click on the Edit button.

Step 3:
Next you should see the Edit Workspace Window. Change the Local Folder Path by clicking on the …

That’s it. You are done. You have changed the Local Path of your working folder in TFS.

Hope that was useful!

How to customize TFS 2010 work items and workflows


Team Foundation Server 2010 and add-ons

We use Team Foundation Server (TFS) 2010 to manage our projects including source control, product backlogs, tasks, and bug tracking.

Our setup consists of:

Customize a TFS work item

When you install TFS Power Tools you get an additional menu option called Process Editor underTools in Visual Studio 2010:

Process Editor menu option in Visual Studio

The Process Editor allows you to edit work item types, either globally or for a specific TFS project.

For example, we can modify the Task work item type to add a custom field by clicking Work Item Typesand selecting Open WIT from Server:

Work Item Types menu in Visual Studio

This brings up a dialog with the available TFS projects. So, if we want to modify the Task work item type for our website’s TFS project we’ll simply expand its node and select the Task work item type:

Work item selector dialog

We click New on the Fields tab to add a custom field:

New field button

Next, we give our new field a name, a reference name, and optionally a description:

Work item field properties dialog

Next, let’s add a rule for specifying available value options for this field. We click the Rules tab and click the Add button:

New rule button

We’ll select the SUGGESTEDVALUES option in the next dialog…

Field rule type dialog

…and then we set group restrictions (optional) and click the New button to add our options:

Suggested field value

Rule dialog

When we’re done we can switch to the Layout tab to add our field to the work item editor:

Work item editor layout dialog

We’ll set a label for the control and select the field we created earlier:

Work item field properties

Now, if we create a new Task work item…

New work item menu

…we’ll be able to see our new custom field in action:

New work item editor

Modify a TFS work item workflow

To modify a workflow you open up the work item associated with the workflow. We could for example modify the workflow for the Bug work item type in order to add additional states to make it fit our work process:

Work item type selector dialog

We click the Workflow tab to edit the workflow associated with the Bug work item type:

Workflow tab

The original workflow for the Bug item type in the Visual Studio Scrum 1.0 template takes bugs fromNew to Approved to Committed and finally to Done – unless they are Removed:

Diagram illustrating workflow for bug items in TFS

We want to rename some of these different states, and also add a few new ones. We do this by pulling up the standard Visual Studio toolbox which, when a workflow is being displayed, gives a few basic – but useful – artifacts to customize the workflow:

Workflow toolbox

Renaming a workflow state

First off we want to rename the somewhat confusing “Approved” state to “Verified” (indicating that the reported bug is indeed a bug), so we simply double-click the red state object and change its name to “Verified”:

State object

We also change the name of the “Committed” state to “In progress”:

State object

When the bug is done we consider it to be in need of approval, so we change the name of the “Done” state to “Awaiting approval”:

In order to allow a product manager, or other similar role, to approve the resolution of a bug we need to add two additional states: “Accepted” and the less popular “Not accepted”. We do this by adding a new State object to the workflow:

Adding new workflow state

We double-click the new State object and name it “Accepted”. We repeat this process for the “Not accepted state:

Renaming workflow state names

To connect the workflow states we click the Transition Link tool in the toolbox and then we click the “Awaiting approval” state followed by the “Accepted” state. We repeat this for the “Not accepted” state:

Adding transition links

When two state objects have been connected by a transition link we see a new blue transition object. We can click the downwards-pointing double arrow to modify the transition object:

Modifying transition links

Each transition must be given a reason which explains why the workflow progressed from one state to the next.

To set the reason why the workflow goes from “Awaiting approval” to “Accepted” we double-click thetransition object connecting them. This brings up the Workflow Transition dialog:

Workflow transition dialog

We switch to the Reasons tab to set the reason(s) the change in state can occur. Simply click New to add a new reason:

Creating a new reason

In this case we’ll say that there are two reasons a Bug item can go into the “Accepted” state: 1) the customer has accepted the resolution (this is the default), or 2) the bug was accepted and given the OK by a developer.

First we’ll add the default reason, when the customer has accepted the fix:

Describing transition rule

Note that field rules can be applied on the Fields tab if necessary.

We’ll also add the second reason a Bug can become “Accepted”, when a developer gives it the OK:

Describing transition rule

So, we now have two reasons for a Bug going into the “Accepted” state:

Workflow transition reasons

We’ll repeat this process for the transition from “Awaiting approval” to “Not accepted”.

We will also add another transition link to allow the Bug item to go from “Not accepted” to “In progress” to allow us to have another go at fixing the bug.

All in all, our revised workflow looks like this:

Diagram of customized workflow

Once a Bug is “In progress” it can be set as “Awaiting approval” (because we believe it has been fixed). The customer can agree which would make the bug resolution “Accepted”. If the customer doesnot agree, the Bug will go into a state of “Not accepted” which in turn means we can start working on it again by setting the state to “In progress”.

We can now try and modify the State field for a Bug item to see the workflow in action. For example, we see that from the “Awaiting approval” state we can go to the “Accepted” or “Not accepted” states:

Work item field

Note: The workflow could optionally be complemented with a transition link from “Accepted” to “Not accepted” with a reason saying the bug was re-opened.