Unable to check out files after using tf destroy
Last friday I decided it was time to clean up some deleted artifiacts in our source code repository. As you might know, deleting files in source control doesn’t really delete them from the repository but just marks them as being deleted. Since some time, however, the tf.exe command line tool allows you to actually remove (or destroy) artifacts from the repository.
I first made an inventory of all artifacts that I wanted to remove from the repository and afterwards started doing just that… To make sure I didn’t mess up I followed the same procedure for all of them:
tf dir xxxx /deleted (where xxxx is the path you want to query, e.g. “tf dir $/ /deleted” to query the root)
As a response you get an overview of all artifacts (folders or files) in the path you specified
E.g.
$/TeamProject1
$/TeamProject2;X999
If an artifact shows up with a semi column and a number at the back, it means this artifact has been deleted from source control but still exists in the repository. If you want you could restore this artifact and make it visible again. Because I wanted to remove them I then issued the “tf destroy” command for these artifacts.
E.g.
tf /preview destroy $/TeamProject2;X999
Which gives you an idea on which artifacts will be destroyed when execting the same command without the /preview option. If you feel comfortable with the artifacts it says it will destroy you can go ahead and re-issue the same command without the /preview option.
E.g.
tf destroy $/TeamProject2;X999
All went well for a while until I got a phone call from some of the developers telling me that they couldn’t check out files anymore. I was certain I didn’t mess up and accidentally deleted files because I never destroyed any files without a semi column and number at the end. So what went wrong?
Lets say the Team Project having issues was called MyCompany.TeamProject, the root source control folder would then be called $/MyCompany.TeamProject. We could still see this folder and the artifacts it contained could still be queried, a get latest or specific worked and getting version info for these artifacts also didn’t pose any problems. But when trying to check out a file we got the following error:
TF10175: The team project folder $/MyCompany.TeamProject does not exist. Contact your Team Foundation Server administrator and ask that it be created
So although the folder was still there, Team Foundation Server seemed to have lost the link between the Team Project and it’s root source control folder.
Now you have to know that before we created the team project called MyCompany.TeamProject, a team project called MyCompany.TeamPROJECT existed but was deleted because of incorrect casing in the name. Because this team project also had a root folder called $/MyCompany.TeamPROJECT, this got deleted (but not destroyed) at the same time we removed the wrongly named team project. So when issuing the command tf dir /deleted we actually got two folders with the same name (if you don’t take into account the casing). e.g.
$/MyCompany.TeamProject
$/MyCompany.TeamPROJECT;X1234
Because the one with the deletion id in the back never contained any artifacts, we assumed it was safe to delete it. Little did we know that the tfs destroy command would mess up and in some way remove the link between the team project and the correctly and still existing team project root in source control.
This case has been filed with Microsoft Support and as soon as I get a solution or the less fortunate reply that there isn’t one, I will let you know. In the mean time we will probably branch (still works) to another team project and merge back when it’s fixed.
Update: Arrived @ work on monday to find that the problem went away by itself. Apparently the warehouse needed an update before it (automagically) re-established the link between the Team Project and the folder in source control. My thx go out to Nitish @ Microsoft Support for reproducing this on one of his virtual machines over weekend and who confirms the warehouse update does the trick.
Thoughts on IT 
Tx!