Search This Blog

Thursday, December 27, 2007

VersionControlPath - Class to Manipulate Version Control Items Path

I was navigating through TFS assemblies and I found out a static class that I wasn't aware of: Microsoft.TeamFoundation.VersionControl.Common.VersionControlPath. This class contains functions that help manipulating version control items path. It is like the System.IO.Path class. Here are some of the methods in the class:
  • GetFileName
  • GetExtension
  • GetFolderDepth
  • Combine
  • GetFolderName
  • ValidatePath

Very useful.

Monday, December 24, 2007

No matching items found in {0} at the specified version

I recently got this error while trying to create a branch from that its parent was renamed.

Here's an example of what happened:

  1. A branch was created at: $/Project/Folder1/Branch1.
  2. Some work has been done on Branch1 so its history contained several change sets.
  3. Folder1 was renamed to Folder2 ($/Project/Folder2/Branch1).
  4. A branch operation failed while trying to create one from a change set before the rename operation with the error: "No matching items found in $/Project/Folder2/Branch1" (A branch operation on a change set created later than the rename operation will succeed).

I thought that the rename operation has broken the branch history. Looking at the branch dialog I saw that the source branch text box is read only and I thought to myself what would have happen if I had changed the source from $/Project/Folder2/Branch1 to $/Project/Folder1/Branch1. It was time for some coding…

private void PerformBranch(string server, string workspaceName, string userName, string changesetId, string sourceBranch, string targetBranch)

{
TeamFoundationServer tfs = new TeamFoundationServer(server);
VersionControlServer vcs = tfs.GetService(typeof(VersionControlServer)) as VersionControlServer;
Workspace workspace = vcs.GetWorkspace(server, userName);
VersionSpec versionSpec = VersionSpec.ParseSingleSpec(changesetId, userName);
workspace.PendBranch(sourceBranch, targetBranch, versionSpec);
}

This method has fixed the problem and after running it with the old branch path (source = $/Project/Folder1/Branch1), pending changes were waiting for check in.

Thursday, December 06, 2007

TF20015: The field 'xxx' contains a value that is not in the list of supported values.

While trying to save a work item in TFS you might be facing a problem doing it when the error TF20015 is raised. This error is raised when you are trying to enter values that are not part of the allowed values of the field. The strange thing is that it can happen although the value was already saved before to the work item and the field is disabled. As a result you cannot change the value and therefor cannot save the work item. So why does it happen? I faced this problem in two cases:


  1. The user in one of the fields (which is implementing the valid user value list as the allowed values for the field) was renamed or deleted.

  2. The work item schema was changed in a way that made some of the existing work items have illegal values. For example, if you made one of the fields mandatory trough all of the work flow and you have some work items with a null value in the field.

So, how can you fix it?


There are 2 ways to do it:



  1. Changing the work item schema temporarily so the field won't be disabled and then you can change the value.

  2. Write some code the change the field value:

Here's a code sample on how to update work item field values:


public void UpdateWorkItem(string serverUri, int id, string fieldName, string fieldValue)
{
TeamFoundationServer tfs = new TeamFoundationServer(serverUri);
tfs.EnsureAuthenticated();
WorkItemStore wis = tfs.GetService(typeof(WorkItemStore)) as WorkItemStore;
WorkItem workItem = wis.GetWorkItem(id);
workItem.Open();
workItem.Fields[fieldName].Value = fieldValue;
workItem.Save();
}


Monday, December 03, 2007

Set Work Item Type field allowed values when another field value changes

I was asked once by a friend if there's a way to filter the allowed values of a field when another field value changes. Well, the solution is not exactly as we think about filtering but more like a switch/case mechanism.

Let's take for example 2 fields that implement OS Platform & Version selection:

Windows --> XP, 2003 Server, Vista

Linux --> Ubuntu, Red Hat, Suse

Mac --> OS X 10.0, OS X 10.5

To implement this in the work item type definition file we need to define 2 fields. The xml should look like this:

<FIELD
type="String"
name="OS Platform"
refname="MyFields.OSPlatform">

<ALLOWEDVALUES>

<LISTITEM
value="Windows" />

<LISTITEM
value="Linux" />

<LISTITEM
value="Mac" />

</ALLOWEDVALUES>

</FIELD>

<FIELD
type="String"
name="OS Version"
refname="MyFields.OSVersion">

<WHEN
field="MyFields.OSPlatform"
value="Windows">

<ALLOWEDVALUES>

<LISTITEM
value="XP" />

<LISTITEM
value="2003 Server" />

<LISTITEM
value="Vista" />

</ALLOWEDVALUES>

</WHEN>

<WHEN
field="MyFields.OSPlatform"
value="Linux">

<ALLOWEDVALUES>

<LISTITEM
value="Ubuntu" />

<LISTITEM
value="Red Hat" />

<LISTITEM
value="Suse" />

</ALLOWEDVALUES>

</WHEN>

<WHEN
field="MyFields.OSPlatform"
value="Mac">

<ALLOWEDVALUES>

<LISTITEM
value="OS X 10.0" />

<LISTITEM
value="OS X 10.5" />

</ALLOWEDVALUES>

</WHEN>

</FIELD>

The version field contains WHEN rule for each platform. The result is a field that changes in real time when the parent field value changes.

You don't have to write the xml in order to achieve this. You can use the "Process Template Editor" which is part of the Team Foundation Server power tools to easily add fields and rules to you work item.