Greetings,
I'm trying to unlock a file which is checked out by another user ( who happens to be out of the office), if i try to do an 'unlock' from the source control explorer i get the message:
The item $/Myproj/MyFile.cs is locked for checkout by THEDOMAIN\theuser in workspace WORKSPACENAME;THEDOMAIN\theuser
I'm a member of the domain admins so i've got unlockother permissions...
Any insight would be much appreciated!< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Unlocking a checked out file in Source Control
Hot Topic
- also confused about licensing (TFS)
- Conflicting changes on folders when merging (in beta3 refresh)
- Request Failed: Unable to connect to remote server
- Load test needs database
- Can we switch licenses between VS 2005 Team Editions?
- Connection to TFS only on HTTP
- Work Items Areas and the WOrk Item OM
- 404 response when trying to connect to team server
- Team Build errors, after build of checkins w/ associated Task from another Team Project
- Fail Team Project creation
VS Team System
- Numerous errors in the Application Event Log when TFS host is rebooted
- Creating a new project fails
- Printing Reports from within Team Explorer
- VB Web Applications - naming fields with camel (WithEvents)
- problems with team build
- Source Control Tree
- Different Source Control options when creating a project
- Office Integration
- TFSDeleteProject Doesn't Remove Project From Source Control
- There seems to be some (to me) wierd behaviour in the generated unit tests...?
Unlocking a checked out file in Source Control
kelton
This is a bug. I was just able to reproduce the same exact situation here in a test environment. I'm not on the version control team so I'm not sure if this is considered a "known issue" or not, but I'm logging a bug for you and will post back with any workaround information that comes my way in the hopes it can help.
---
Eric Jarvi
http://blogs.msdn.com/ejarvi
K-ERoL-K
Actually, when you specify commands via the Source Control Explorer window, the system tries to run them on the current workspace selected in the workspace dropdown. The file is not actually locked in your workspace, hence you're getting the error message.
You can do this through the command line client (start -> all programs -> visual studio 2005 beta 2 -> visual studio tools -> visual studio 2005 command prompt). You have to specify the other user's workspace using the /workspace option.
h lock /lock:none $/<full path to the file>/filename /workspace:usersworkspacename
For example, say that Joe has a file locked in workspace "JoesWorkspace"
h lock /lock:none $/TeamProject/WidgetProject/Widgets/main.cs /workspace:JoesWorkspace
Thomas Kionka
No workspace matching XXX found on this computer.
Tom Rizzo - MSFT