TFS Workspace Gotcha!

Aaron Kowall — Mon, 11 Sep 2006 20:55:00 GMT

I have been working with a team that has recently migrated a TFS source project from a trail TFS to a full production server (different server). They disconnected their solution from source control (removes all the SCC stuff from .sln) files and then tried to add to the new TFS.

However, they were getting weird errors.

I suggested that they might not have their workspace mapped correctly to the new TFS project.

When they tried to map the workspace, they got the following error:

The Path <local path> is already mapped in workspace <machine name [old tfs server]>

Hmm, I thought we removed all the source stuff?

Turns out that the workspace mappings are stored in a file called:

VersionControl.config under the users local settings/application data directory.

I could find no way (other than manually editing the forementioned file) to remove the workspace mapping from that local folder to the other TFS server (which is no longer in usage).

Anyway, once that was done, all was good in the world.

Thanks go out to Kevin Jones for his excellent post on Workspaces in TFS.

How to handle unwanted Work Items in TFS

Aaron Kowall — Tue, 27 Jun 2006 01:04:00 GMT

I’ve been travelling with my buddies Etienne Tremblay and Wayne from Microsoft all over the world talking to project teams about using VSTS and TFS. [See Etienne’s Blog for the chronicles of our trip] One topic that inevitably comes up is the fact that work items can’t be deleted. Normally, I totally agree with this practice. If a workitems was created with intent, then it should run it’s lifecycle. However, since managing projects with TFS can driven using the warehouse metrics and reports, it becomes problematic when workitems are created accidentally and can’t be deleted. I’ve considered adding a ‘deleted’ state to some of the workitem types (especially task) and filtering out the ones marked ‘deleted’ from the queries. However, I’m worried that this will add significant overhead to queries to include the ‘not deleted’ condition. Also, it’s unclear what adding this state would have to reports within the TFS. I haven’t taken the time to look through all the reports to determine whether results would be misleading by adding this new state.

Has anybody out there considered this solution? If not, how are you addressing these mistaken work items?

Aaron

Visual Studio

TFS Workspace Gotcha!

How to handle unwanted Work Items in TFS