It’s inevitable… You’re under a tight deadline to make a critical bug fix and someone else has the file you need to change locked. You rush around and find someone with administrative rights to help out. Here’s what they do:
h lock /lock:none $/OurTeamProject/WidgetProject/filewidgets.cs /workspace:joesdevbox
And voila! You’re back in business! The /workspace parameter specifies the short name of the workspace the other user has the file checked out in. If there are multiple workspaces with the same short name, you can qualify it by adding the user’s domain\username. For example: /workspace:joesdevbox;CORPORATE\joelewis. The full server path is required to specify the exact item you want to unlock. A benefit of requiring the full server path is that the administrator doesn’t even need to have a workspace with all the files sunc down just to unlock someone else’s changes.
Currently, there’s no way to do this through the GUI. When you right-click on an item in the Source Control Explorer and choose “unlock”, the action is issued against the current workspace selected in the workspaces listbox.