Type definitions overwritten every night

A small problem has come to light. I successfully exported and modified the Task.xml and Bug.xml type definitions. I then imported the changed template successfully. Subsequent changes to the templates were made and imported via witimport.exe. Any changes I made were reflected in any new bug or task added to the test project.
We already had an existing project up and running, setup with the original basic MSFAgile template. When it came to use the new templates everything went well. Import was successful, no errors, and test work items could be created and pushed through the new process.
However (there's always at least one "however") a problem has arisen. Overnight something happens to the new Task.xml. The type definition remains mostly the same (newly added fields and drop downs are still available) except the new states vanish, leaving the default Active, Closed and Resolved.
The only jobs running on the server overnight is a backup. Nothing else. I don't understand why it's only new states (and by default the transitions) that are getting rolled back to the old setting. Has anyone else noticed this behaviour?
[1206 byte] By [JamesHill] at [2007-12-16]
# 1
The only other scheduled task that is running is the TFSSchedulerService which kicks syncing of user/groups, CSS nodes etc... into workitem tracking. That shouldn't over write constants like the states list and it doesn't seem like corruption as it always seems to revert back. There is nothing in the product that should do this.

Couple things to try:
1. Stop the TFSScheduler service and see if it repros
2. select from the currituck constants table and see if the added states are present or if they are disappearing from the DB for some other reason.

Bryan MacFarlane
WorkItem Tracking dev lead

BryanMacFarlaneMSFT at 2007-9-9 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...
# 2
A little update on this and thanks for the reply.
The same thing is happening in the test environment. It too only had the three default states when I first started working on the xml but was behaving itself at my last posting. Now it seems to have reverted too.
I checked the constants table and the new states exist in the db. I'll shut down the scheduler and see what happens.
Thanks :)
JamesHill at 2007-9-9 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...
# 3
Shut down the TFSSchedulerService and all is well again in my world. Sorry it took so long to get back.
Any particular reason why this should work? And has anyone else come across the same problem?
JamesHill at 2007-9-9 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...
# 4

The TFSScheduler should not affect states under normal circumstances, because state data is stored locally in the WorkItemTracking database, so the behavior you are seeing is not something I'd expect. Can we take a look at the contents of this workitemtype? If it is possible to run a diagnostic tool on the server and send us the result, please send mphilip@microsoft.com an email alias, and I'll send you the tool (it's a file that is a few kb's) and usage instructions.

Thanks.
-Mareen.

MareenPhilip. at 2007-9-9 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...

Visual Studio Team System

Site Classified