Im working my way through an unusual TFS issue:The item $//Security/Security.vsd is locked for check-out by (null) in workspace (null).
The problem appears to be a changed workspace while the item was checked out.
Thanks to James Manning for the following command line check:
tf lock $/MyProject/MyPath/MyFile.cs /lock:none /workspacename:WorkSpaceName /server:my_server
The easiest fix is to get the other workspace(s) with pending changes to either undo or checkin their changes. You can see who has pending changes with:
Tf status /user:* $/Security/Security.vsd /server:my_server
I also found, whilst doing researchon the issues, some excellent TFS top tips here:
Brian Harry on Cool work item add-on. David McGhee on TFS lock checking. Paul Hacker on Cool WorkItem...
I also ran into this problem of team foundation server saying a file is checked out by (null), but neither "tf undo" nor "tf lock" commands would make any difference, and "tf status" would not return the status of the file either. Also tried enabling multiple checkouts and trying to check out with another user to at least populate the mutiple check outs with at least one valid lock, but couldn't do this either as the lock by (null) was an exclusive lock. Couldn't delete it via visual studio either, obviously as it required a lock.
In the end I reverted to backing up the file locally, issuing a "tf destroy" command (below) from the visual studio command prompt, and readding the file via solution explorer.
For the above example the command would just be:
tf destroy $/Security/Security.vsd
Everything is back to normal now, except I've lost the change history of the file.
Another solution here : msdnrss.thecoderblogs.com/.../orphaned-locks-in-tfs
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
FROM tbl_Lock l
LEFT JOIN tbl_PendingChange pc
ON l.PendingChangeId = pc.PendingChangeId
WHERE pc.PendingChangeId IS NULL