Undo a check out in Team Foundation Server source controlOctober 3, 2007
Almost every team that uses source control will inevitably find themeselves in a situation where a file is checked out and locked and needs to become available for someone to work on it. Often the person who has the file checked out is currently on holiday or has left the company or, as with our recent situation, the original machine used for the check out no longer exists.
In Team Foundation Server source control, the workspace is a local copy of the files on the server and this copy is isolated from any other changes that may occur on the files. You can in fact have multiple workspaces across different machines – something that happens frequently for contractors who hot-desk.
If one of these machines is rebuilt or simply dies, the original workspace relationship on the check out in source control remains and the file can never be checked in.
So how do you undo a check out?
First, you must have administation priviliges; secondly, if you are not in a domain-controlled environment (as is our situation) you have to be on the team foundation server itself.
Using the Visual Studio 2005 Command Prompt, you can make use of the TF command-line utility to issue a command to undo or unlock the check out.
In our experience, the Undo Command was the operation best served to reverse the check out and lock actions as this “removes pending changes from a workspace”:
TF UNDO $filepath$ /Workspace:$workspace$;$user$ /s:$server$
e.g. TF UNDO $/MyProject/Folder1/File1.cs
Note that you must specify the workspace and user that you wish to reverse actions for – if you are unsure of the current workspace that the file is checked out under, simply go into your source control and attempt to check the file out.
You will receive a warning informing you of the user and workspace the file is checked out to.
Note that when you run this command successfully what appears to be a yellow error comes up in the command window:
“The workspace MX4545;john.smith is not on this computer. Run get (get all if edits were undone) on the computer hosting that workspace to update it with the changes that have been made on the server.”
This is infact showing you that it was successful but the files for that workspace/user require a get latest to become up to date with your undo changes you have made.
An alternative method to unlock the file is the Lock Command:
TF LOCK $filepath$ /lock:none /Workspace:$workspace$;$user$ /s:$server$
… but we found this problematic due to the following note in the msdn documentation:
Having the Unlock other user’s changes permission set to Allow is required to remove a lock held by another user if you do not have Write permission for that user’s workspace.
One other handy command related to this is the Status Command with which you can obtain a list of all files checked out to a particular user – particlarly useful when a user no longer exists and you need to undo all files checked out by that individual.