TFS, Version Control, Branching, and Repository Cleanup

Lesson learned the hard way: When setting up TFS branching strategies, read the Microsoft Patterns & Practices branching guidance CAREFULLY before creating your repository structure. Fixing it later requires nuclear options.

The Mistake

At 3Metas, we use Visual Studio Team Foundation Server 2008 (VSTFS2008) as our project management and version control system. When creating our solutions, I made a critical error: I didn't carefully review the Microsoft Patterns & Practices Branching Guidance.

The result? Projects and documentation were working fine, but the source control schema was incorrect. This meant our branching strategy wouldn't scale properly, merge operations would be painful, and we'd accumulate technical debt with every release.

Why Branching Strategy Matters

A proper branching strategy is critical for:

• Isolating development work from stable releases
• Managing parallel feature development
• Handling hotfixes for production without disrupting development
• Supporting multiple release versions simultaneously

The Nuclear Option: tf destroy

The solution? Destroy the source control repositories (after backing up, of course!) and reorganize the system properly.

To destroy a source control repository, use the tf destroy command. You'll find it at: Program Files\Microsoft Visual Studio 9.0\Common7\IDE\

Using tf destroy


            cd "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE"

            tf destroy $/YourProject/Branch /server:http://your-tfs-server:8080

A confirmation dialog will appear, then the system will list all files and folders being deleted. This is permanent—there's no undo. Make sure your backups are solid.

Rebuilding the Repository

After destroying the repository, use Visual Studio 2008 with Team Explorer to access the source control management interface. From there, you can recreate the repository and configure it correctly according to the branching guidance.

Important: Reassign Permissions

Users who had permissions on the project will still have those permissions, but they'll lose permissions on the source control repository specifically. You must reassign these permissions in the Security tab of the repository properties.

Step-by-Step Recovery

Backup Everything

Create a complete backup of your TFS database. Test the restore process. This isn't optional.

Use tf destroy

Run the destroy command to permanently remove the incorrectly structured repository.

Recreate Repository Structure

Using Team Explorer, create the new repository following proper branching guidance (Main, Dev, Release branches as appropriate).

Restore Code

Check in your code to the properly structured repository.

Reassign Permissions

Go to repository properties > Security tab and reassign user permissions.

Important Distinctions

tf destroy vs. Deletion vs. Project Removal

Regular Deletion (Delete command)

Only marks the repository as deleted but it still exists in the system. You can see deleted items via: Tools > Options > Source Control > Visual Studio Team Foundation Server and check "Show deleted items in Source Control Explorer."

tf destroy

Permanently removes the repository from TFS. This is irreversible and complete destruction.

Project Removal

Deletes the entire project including portal, documents, work items, etc. We didn't want this—we only needed to fix the source control structure while keeping everything else intact.

Why TFS Matters for Distributed Teams

Team Foundation Server is a "must-have" tool for a technology company like ours. The combination of version control, project management, customizable development methodology, and more makes it indispensable for the model we're building—a company where each person can work from wherever they want.

Even if you don't use VSTFS2008, any software development company must have a version control system. An internet-based system adds tremendous flexibility. We've also used Subversion with good results.

Modern Context: Version Control in 2025

Looking back from 2025, the version control landscape has evolved:

• Git dominates: Git-based systems (GitHub, GitLab, Bitbucket) are now standard
• TFS evolved to Azure DevOps: Microsoft's offering modernized significantly
• Branching strategies are well-documented: GitFlow, trunk-based development, feature flags
• Distributed VCS is default: Centralized systems like TFS/SVN are rare
• Monorepos gained traction: Large companies use sophisticated monorepo tooling

But the core lesson remains: get your branching strategy right from day one. The tools changed, but the pain of fixing bad repository structure after the fact hasn't.

Lessons Learned

1. Read the branching guidance BEFORE setting up your repository, not after.
2. Plan for scale from day one—branching strategies are hard to change later.
3. Test your branching model with a small team before rolling it out company-wide.
4. Document your branching conventions so everyone follows the same patterns.
5. tf destroy is a last resort, but sometimes it's the right tool for the job.