Lies TFS Told Me

This morning we suffered an air-conditioner failure in one of the server rooms. As our TFS server was deployed to a server with the words "dev" in it, naturally they thought they could just shut it down. After all, dev means development so it's not critical. I don't blame them however it caused a few issues. This one was shared to me by one of my developers so hopefully it'll help some of you out there in TFS land.

So apparently if the TFS server goes down while you're working on a file Visual Studio will allow you to work on the file locally. Makes sense. However, while editing the file, the server does not know that you have updated the file. Thus, when you reconnect to the server (or in this case the server comes back from the dead) TFS doesn't realize the file has been modified and will not save the changes to the repository when you complete a check-in.

To get TFS to check-in the modified file you must specifically go to each of the modified files and select Check Out for Edit. Then, select None - Allow shared checkout and click the Check Out button from the Check Out dialog that appears. Finally, check-in (commit) the files back to the source repository. 

The one other symptom is that your local files are not set to read-only like all other files when you try to update from the repository (Get Latest Version).

Something to watch out for in case your server goes bye-bye in mid-development.

2 Comments

  • I thought there would be outright lies like the one it sometimes tells me about files I don't have a local copy of.

    "You already have the most recent version of the file."

  • @Andrew: Actually (at least my copy) does tell me that from time to time. It'll tell me I have something checked out and it's different, but when I run the compare facility it says "Files are identical". Nice.

Comments have been disabled for this content.