This documentation is archived and is not being maintained.

Create and Work with Workspaces

Your workspace is a local copy of your team’s codebase. Your workspace enables you to develop and test your code in isolation on your dev machine until you are ready to check in your work.


See Team Foundation Server Permissions.

What do you want to do?

To add, edit, or remove a workspace, choose Workspaces on the Workspace menu in Source Control Explorer. The Manage Workspaces dialog box appears.

Manage Workspaces dialog box

Choose Show remote workspaces if you want to view all the workspaces you own (including those on other computers).

If you want to reuse or share folder mappings with other team members, you can copy the folder mappings. Simply open the shortcut menu in the Working folders list and choose Copy. To reuse the folder mappings, paste them into another version control workspace or a build definition workspace. To share the folder mappings with your teammates, paste them into a text file and then share the file.

When you choose the Advanced button on the Add Workspace or the Edit Workspace dialog box, some additional options appear.

  • Owner: Only the owner of a workspace can use it.

    Tip Tip

    Instead of changing the owner of your workspace when someone else needs to continue your work you can suspend (or shelve) your work and then share the shelveset with them.

  • Computer: This box identifies the dev machine where the workspace exists, and it is read-only. You cannot move a workspace from one computer to another. However, if the name of your dev machine has changed and you want that change to appear in this field, run tf workspaces /updatecomputername.

  • Permissions: For a workspace you are using on a dev machine for a single developer, set this to Private workspace.

    Choose Public workspace if you want to use a single computer for a team to collaborate on an effort such as resolving a large number of conflicts. If you want any team member to be able to use a workspace but not check in their work, choose Public workspace (limited). This option reserves check in permission for the Owner.

  • Location: The default value of Local is the best choice in most cases. See Decide Between Using a Local or a Server Workspace.

  • File Time:

    • Choose Checkin if you want the date and time stamp of each file to match the stamp of the changeset of the version in your workspace. See Understand the Checkin File Time option.

    • Choose Current if you want the date and time stamp to match the date and time when you last modified the local file. For example, a team member checked in the latest change to the file on Monday. On Tuesday, you perform a get operation to update the file. The date and time stamp is set to Tuesday.

When you switch from one workspace to another, to avoid confusing yourself, make sure you switch to the same workspace in both Team Explorer and Source Control Explorer.

To switch workspaces

  1. If you are not already connected to the team project that you want to work in, then connect to the team project.

  2. Choose Home icon Home, and then choose Pending Changes icon Pending Changes.

  3. If you have multiple workspaces, then the name of your active workspace appears underneath the page title. Choose the name of the active workspace to view a list of all your workspaces on this dev machine.

    Choose a workspace in Team Explorer

    On this menu, choose the workspace you want to work in.

  4. Choose Home icon Home, and then choose Source Control Explorer.

  5. In Source Control Explorer, open the Workspace menu and then choose the workspace the workspace you want to work in.

    Switching workspace in Source Control Explorer

When you choose Checkin for the File Time option, as explained above, the date and time stamp of each file generally matches the stamp of the changeset of the version in your workspace. A few issues and exceptions are:

  • When you modify the local file, the date and time stamp will match the date and time when you modified the file.

  • This feature is available only if you are using Visual Studio 2012 or later and Visual Studio Team Foundation Server 2012 or later.

  • The setting does not apply to folders, unless there is a pending add or delete operation to a file contained by the folder.

  • You might not be able to build your code project incrementally. Instead, you will have to rebuild).

You can create and manage your workspaces from the command prompt. See Workspace Command, Workspaces Command, and Workfold Command.

Tip Tip

You can use the command prompt to perform some tasks that are not possible in Visual Studio. For example, you can delete another user’s workspace if you have sufficient permissions. See Workspace Command.