I noticed this blog post tonight and was trying to add the below as a comment to it - I've tried submitting it 3 times and it doesn't seem to work (no error message, just the post back gives the same form with the same contents as I just posted), so I'm going to put the comment as a blog post here and instead leave a link on the blog instead.



Hi Rama!

Sorry you had such a difficult time of it, but I'll try to explain what options were available.  One thing I want to emphasize up front, though: this situation is one we've very much planned for, and while it sounds like we could definitely make it more clear how to recover from this (it sounds like a great blog post for me to write! [:)] - the support is definitely there in our system.

First, I'm not sure why there was a problem with web.config - Team Foundation supports multiple checkout by default (so any number of people can check out a file at the same time.  This is configurable both at the Team Project level (so all contents of the team project are "single checkout") and by file extension (there's a list of file extensions configured by default, with types that we know aren't mergable, like .dll, .exe., etc., being listed as such so only one person can have it checked out at a time.  Since .config files are xml based, they are very much files you can do content merges on, so by default when you check out a file like web.config, there isn't a checkout lock taken (that's how we enforce the "one checkout at a time" for such files).

Since you were getting the error that it was locked in his workspace, it sounds like there was a checkout lock he placed on the file.  The 2 things that cause a checkout lock to be taken on a file at checkout time by default are 1) if the whole team project has multiple checkout turned off and 2) if the extension of the particular item has been configured as "not mergable" in the server source control configuration.  It's not overly relevant how the checkout lock got there, I just wanted to include that information in case it's unclear why that lock was there.  There's also the chance that they chose to take the lock explicitly at checkout time (or even after doing the checkout).  In either case, the default configuration and setup doesn't cause checkout locks on .config files since they're just XML and you should be able to do content merge operations on those kinds of files just fine.  When it came up in our design meetings, it was usually along the lines of "takes locks on files, goes on vacation", but it's the same effect [:)]

FWIW, the location of tf.exe is in the same dir as devenv.exe (VS itself), by default it's %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE.  Note that you'll need to have installed the "Team Explorer" bits in order to have tf.exe (it's the same bits that give you the Tools -> Connect to Team Foundation Server option in the menu).  Also, to help with usage of tf.exe, the command line reference is up on MSDN @ http://msdn2.microsoft.com/library/cc31bk2e(en-US,VS.80).aspx

As an admin, there are at least 2 different things you could do if this situation happened.

1) As an admin, you have the UnlockOther permission to all items in the version control repository.  This means that you can undo anyone else's locks on any item.  The command-line for that would be something like: tf lock /lock:none $/whatever/item/goes/here/web.config - there's likely a UI method as well, but I don't know off the top of my head (writing this at home, don't have TF installed here).  The lock command is covered @ http://msdn2.microsoft.com/library/47b0c7w9(en-US,VS.80).aspx

2) As admin, you also have the global version control permission AdminWorkspaces - this gives you the simpler and cleaner approach that you can just delete that user's workspace (you don't have to do it from his machine).  That will take with it any pending changes, any locks, etc. that the workspace was holding.  The command is just: tf workspace /delete hisworkspace;DOMAIN\hisuser - the workspace command is covered at http://msdn2.microsoft.com/library/y901w7se(en-US,VS.80).aspx

Since the user has moved on to another project, deleting his workspace is likely the better answer, and as I mention above, it's also the cleanest since you don't have to manually undo that checkout lock (or worry about that user potentially having other locks being held in that workspace).

If I can help any with this, please let me know either by contacting me or posting a comment on my blog.  Also, we are very active on the Visual Studio Team Foundation forum @ http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=22&SiteID=1

Hopefully this comment has helped a little, and I'll make sure to contact our docs team about getting this made clearer in our final bits and try to get together a blog poston the topic (largely copying this comment :) once we can get the RC out the door.  As a side note, if you're running Beta 3 Refresh now, please upgrade to the RC if at all possible - we really want everyone possible to bang on it to make sure it's absolutely rock solid for our final RTM bits!

Thanks, Rama!  Please let me know if you still have any questions or if I wasn't clear on any of the above.