Working with Source Control Workspaces
A workspace is your client-side copy of the files and folders on the source control server. When you add, edit, delete, move, rename, or otherwise manage any source-controlled item, your changes are persisted, or marked as pending changes, in the workspace.
A workspace is an isolated space where you can write and test your code without having to worry about how your modifications might affect the stability of checked-in sources or how you might be affected by changes that your teammates make. Pending changes are isolated in a workspace until you check them in to the source control server.
You can synchronize your workspace with the most recently checked in changes on the server by using the Get Latest command.
If you want to have multiple copies of source on your computer, you can create more than one workspace for a specific source control server.
Maintaining Multiple Workspaces
Team Foundation is designed in such a way that you do not have to create multiple workspaces on your computer to complete everyday tasks. A single workspace can contain multiple team projects. For more information, see How to: Add and Remove a Working Folder in a Workspace. However, you can create more than one workspace on your computer for many reasons. Two of these reasons are described here.
First, you might want to maintain multiple copies of source, each pointing at different versions. This can be helpful if you are working on a new release but need to be able to refer back to the source code from a previous release.
The second reason to consider creating a "test workspace" on your computer is to make it easier to complete code reviews. If you typically build and test other people's code as part of a code review, you might want to create a dedicated workspace.
In This Section
- How to: Create a Workspace
-
Describes the steps taken to create a workspace.
- How to: Add and Remove a Working Folder in a Workspace
-
Explains the steps that are used to add and remove working folders in a workspace.
- How to: Edit a Workspace
-
Explains the steps that are used to edit an existing workspace.
- How to: Cloak and Decloak Folders in a Workspace
-
Explains the steps that you must follow to cloak and uncloak folders in a workspace.
- How to: Remove a Workspace
-
Describes the steps that are used to remove a workspace.
Reference
Related Sections
- Getting a Local Copy of Files from the Source Control Server
-
Provides information about getting source control files and folders for a team project associated with a local workspace.
- Team Foundation Source Control Walkthroughs
-
Lists walkthroughs which explore using source control, customizing a source control check-in, and using source control from the command line.
- Administering Team Foundation Source Control
-
Lists topics that apply to administrators of Team Foundation source control.
See Also
Workspaces are tied to machines they are created in. For one of our projects I need to keep the local source code on an external hard drive and connect it to different machine to debug problems related to those specfic machines. I couldn't find a way to use the workspace I had on my external drive.
I suggest give some info on the format and the location of the information kept on workspace. Maybe one could edit this information to fix these kind of issues.
Location:
C:\Documents and Settings\[user]\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache\VersionControl.config
Details:
I ran into an annoying situation when I reinstalled foundation server to transition from a two server setup to a single server setup. I have TFS installed on virtual machines, and I left the machine name the same as my original application tier. When I brought up a project that had been source code controlled on the original server, Visual Studio smartly told me that the project no longer existed on the server and gave me the option to remove the source code control bindings from the solution. I did, but unfortunately, Visual Studio wouldn't let me re-add the now un-controlled and un-bound project to the newly installed server. It gave me an error about how it was already bound to another workspace pointing to the old server using an old acount. I deleted the workspace using the UI, but I still received the error (and the workspace would reappear after the error!). I was able to hunt down the setting in the very easy-to-read file in the above location, removed the old workspace information, and everything worked great afterwards. Later I googled the file name; out of 8 results, I thought the below blog entry about the server part of workspaces and workspace behavior was interesting.
- 6/22/2006
- TexasJason
