Export (0) Print
Expand All

Create and work with workspaces

Your workspace is your local copy of the team’s codebase. This is where you develop and test your code in isolation until you are ready to check in your work. In most cases the only workspace you need is created automatically for you and you don’t have to edit it.

In some cases, you might want to modify your workspace or create multiple workspaces to isolate and switch among the changes you are making in different branches.

After you have connected to the team project (Keyboard: Ctrl + 0, C), you can manage your workspaces from the Team Explorer home page (Keyboard: Ctrl + 0, H)

Manage workspaces from Team Explorer

or from Source Control Explorer.

Editing workspaces from Source Control Explorer

Manage Workspaces dialog box

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

After you choose Add or Edit you can modify working folders in a new or an existing workspace.

Edit Workspace dialog box

Why would I need to change the folder mappings? How should I do it?

How do I choose advanced options?

If you want to remove the workspace, before you do so, make sure there are no pending changes (Keyboard: Ctrl + 0, P). If you have pending changes, you can either check them in or shelve them.

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.

  1. Connect to the team project (Keyboard: Ctrl + 0, C).

  2. On the home page (Keyboard: Ctrl + 0, H) choose the workspace you want to use.

    Switching workspaces from Team Explorer Home page
  3. In Source Control Explorer, choose the workspace the workspace you want to work in.

    Switching workspace in Source Control Explorer

You can create and manage your workspaces from the command prompt. You can also 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, Workspaces Command, and Workfold Command.

A: In general, you should map your entire team project to a single local folder under c:\Users\YourName\Source\Workspaces\. For example:

Edit Workspace dialog box

Some tips on effective folder names:

  • Keep all folder, sub-folder, and file names short to simplify your work and avoid potential long-path issues that can occur with some types of code projects.

  • Avoid whitespace if you want make command-line operations a little easier to perform.

If your team has a large and complex codebase or if you want your workspace to contain only the files you need to improve performance, you can optimize your workspace.

A: Yes. 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.

A: Choose Cloaked to exclude that folder from your workspace. For details and examples, see Optimize your workspace.

A: When you choose the Advanced button, 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: 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 generally match 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).

    • 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.

A: Although Visual Studio does not block you from running multiple instances against the same workspace, this usage is not supported. Also, working this way is more likely to cause problems if you are using a local workspace.

Show:
© 2014 Microsoft