Workspaces in TFVC
Ok, I just read http://blogs.vertigosoftware.com/teamsystem/archive/2006/01/27/2051.aspx, which was linked to by the Team System News feed (great job Mickey - YOU rock!).
This posting confused me a bit, as it didn't seem really address the whole workspace concept - which is critical to check-outs. So yes, a check-out simply marks a file as writeable with the idea that it has "pending changes". If you immediately check the file in, the IDE will tell you that there are no changes, and nothing happens. So that left me with an empty feeling that I just had to discuss...
So let's talk about what a workspace is, as this is a common point of confusion for people moving from VSS. A workspace is similar to your local "working directory" in VSS, but it has same major differences. First off, a workspace is "owned" by a user. For example:
I was working with a client that had a person using a laptop and had a workspace mapping to a particular directory (for this example, c:\projectfiles). When your workspace is setup using that directory, the Team Foundation Version Control system "knows" what user is using that directory on that machine. The server keeps track of this, as well as every single file that you have in that directory, and which version of those files you have. This is why if you delete a file using windows explorer and then say "Get Latest" it does nothing. The server believes you have the file, so why waste the network traffic sending it to you again - surely you weren't stupid enough to delete it? :-) Anyway, back to the customer problem - they person using the laptop left the company, and they gave the laptop to another developer. That new developer attempted to use the exact same directory (c:\projectfiles) for their own workspace mapping. TFVC didn't like that, as that workspace was "owned" by the original user, and they weren't allowed to use it. To fix this, you have to delete the workspace from the server (not just delete the files locally).
So - workspaces are owned by users and they are managed at the server level. There are some cool things about this, for example, if you edit your workspace mappings (under the File -> Source Control menu), and change one of your local directory mappings, the Version Control client will "magically" move all the files from the original directory to the new mapped directory - after all, the server now knows where they should be. Another interesting note is that workspace are by user and by machine. So if I login to a 2nd computer, I essentially have a new workspace - with new mappings, and with potentially different files in it. If you login to my computer you will have a different workspace than I do on my computer - just don't use the same directory!
Anyway - I hope this provides some insight into workspaces, as many times as I've explained it to clients, I still don't feel that I have a "simple" description...