Category: Team System

TF26212: Team Foundation Server could not save your changes.

I created a new WIT (work item type) to track progress of a set of activities we have here. Let’s call it “Setup”.

I wanted to restrict the users that create a new instance of the work item. The way to do this in TFS is to put a restriction on the state transition from “” to the first state of your workflow: “FirstStep” in our case.

To make things easier, I gave the group the same name of the WIT: “Setup”.

So I ended with something along the following lines:

<?xml version="1.0" encoding="utf-8"?>

<witd:WITD application="Work item type editor" version="1.0" xmlns:witd="http://schemas.microsoft.com/VisualStudio/2005/workitemtracking/typedef">

  <WORKITEMTYPE name="Setup">

    <WORKFLOW>

      <STATES />

      <TRANSITIONS>

        <TRANSITION from="" to="FirstStep" for="[project]Setup" />

      </TRANSITIONS>

    </WORKFLOW>

  </WORKITEMTYPE>

</witd:WITD>

 

The problem is that when I tried to save a new instance of the work item, I received the following message from TFS:

TF26212: Team Foundation Server could not save your changes. There may be problems with the work item type definition. Try again or contact your Team Foundation Server administrator.

That really doesn’t help…

After some research I found a blog post with a solution to the problem.

The problem is you should not have a WIT with the same name of a TFS group in whatever Team Projects you have.

TeamBuildTypes and Source Control Restructuring Gotcha

As part of implementing branching for the project I’m currently working on, I had to do some restructuring of the source control folder structure.

The structure was generally well organized except for the fact they didn’t take branching into consideration when setting up the folder structure:

$

  • Project
    • AnalysisServices
    • Assemblies
    • DatabaseObjects
    • IntegrationScripts
    • Models
    • OldLabBranch
    • TeamBuildTypes
    • Etc.

I wanted to create a branch in where AnalysisServices, Assemblies, DatabaseObjects and IntegrationScripts could be isolated in conjunction so new feature development could be done in parallel with regular maintenance without one breaking the other.

Using the branching guidelines I’ve talked a couple of posts ago, I managed to structure the folders as below:

$

  • Project
    • OldLabBranch
    • Main
      • Sources
        • AnalysisServices
        • Assemblies
        • DatabaseObjects
        • IntegrationScripts
      • TeamBuildTypes
    • Models
    • Etc.

The problem with this setting is that your Team Build Types won’t show up in Team Explorer 2005 because it has a dependency of TeamBuildTypes being a direct child of your Team Project’s folder. Moving back TeamBuildType to $/Project did the trick and everything worked fine.

$

  • Project
    • OldLabBranch
    • Main
      • Sources
        • AnalysisServices
        • Assemblies
        • DatabaseObjects
        • IntegrationScripts
    • Models
    • TeamBuildTypes
    • Etc.

When we upgrade to TFS 2008, I’ll move back TeamBuildTypes to the place recommended by the guidelines as they really do make sense.