For many of using Team Foundation Server on a daily basis, living with the TFS workspace has been a love/hate (mostly hate?) relationship. A simplistic definition, if you’re not familiar with TFS’ workspace, is that it is a mapping of a selection of files within TFS version control to their corresponding destination on your local file system along with various related status information. This workspace mapping is stored on the server – not the client (i.e. server workspace).
The down side is that it is relatively easy to get your local file system out of sync with what TFS thinks it knows (about the status of the mapped files). If you delete a file on your local file system, TFS has no idea that the file has been deleted. If you modify a file on your local file system (assuming you remove the “read only” attribute) then TFS has no idea about that change. These examples, along with others not listed, adds to some of the greatest confusion when learning to use TFS version control for the first time.
On the up-side, the beauty of the server workspace is that TFS will send down only the files necessary based upon your request (i.e. “Get Latest”). This can be very useful if you’re working across a WAN/VPN connection where bandwidth is at a premium.
Enough about the current state of affairs. Now, the good part… Brian Harry has posted some details around some of the enhancements being made to version control with the next release of Team Foundation Server (a.k.a. “Dev11”). In this post, he discusses the addition of the “Local Workspace” which allows you to make changes directly to the files within your file system and TFS will automagically recognize and handle those changes. This will provide SVN-style version control capabilities with TFS. Server workspaces will still exist but the local workspace will become the default.
Check out Brian’s post for all the nitty gritty details.