This project is read-only.

How to define workspace mappings

- J.D. Meier, Jason Taylor, Alex Mackman, Prashant Bansode

Define a workspace mapping to map source control files and folder on the server to your local drive.

To create a workspace mapping for a project that is not yet on your hard drive
  1. In Source Control Explorer, select the root source folder.
  2. Right-click and select Get Latest Version.
  3. Choose the local folder to which you want to map the workspace.

To modify a workspace mapping for a project that is already on your hard drive
  1. Select File->Source Control->Workspaces.
  2. Use the Manage Workspaces dialog box to add, remove, or edit existing workspaces.

To view an existing workspace mapping
  1. In Source Control Explorer, select a source folder.
  2. Right-click and then click Properties.
The workspace mapping to your local drive appears in the Local Name field.

Consider the following best practices for creating workspace mappings:
  • Create mappings at the team project root level. For new team projects, map your team project root ($/MyTeamProject) to a folder with the same name on your local drive; for example, C:\TeamProjects. Because mappings are recursive, your entire local folder structure is created automatically and will be exactly the same as the structure in source control.
  • On shared computers, use a unique local folder path. Two users of a single computer cannot share the same workspace mapping. For example, you and a colleague cannot map the same team project ($/MyTeamProject) to the same folder on the local computer. Instead, create mappings beneath My Documents (although this leads to long location paths) or establish a team folder-naming convention on the local computer (e.g., C:\TeamProjects\User1, C:\TeampProjects\User2 etc).
  • You might not need the entire tree. To improve performance and reduce disk size requirements, only map the files you need for your development project. In general, you will only need the files and projects associated with the solution on which you will work.
  • Avoid using workspace mapping to support cross-project dependencies. In general, you should avoid dependencies that cross team projects and try to have all the related/dependent solutions/projects under same team project. This reduces the need for build script customization. If you have a dependency, use project references to define the dependency, or branch the dependency from a shared project into your project. You should avoid file references because they are more difficult to manage. The exception is when the dependent project is developed in parallel and you need real-time changes. In this case, you can consider the using workspace mapping. You can still consider branching to create a buffer of isolation, if the dependent code is causing too many breaking changes.

Additional Resources

Last edited Jul 31, 2007 at 4:14 PM by prashantbansode, version 7

Comments

MikeLerch Nov 4, 2009 at 12:31 PM 
I'm struggling to implement the best practice for workspace mappings and the following line is very confusing: "For new team projects, map your team project root ($/MyTeamProject) to a folder with the same name on your local drive; for example, C:\TeamProjects." If we should use a folder with the same name, shouldn't we map to "C:\ MyTeamProject"?