I’ve been working with our content team to help publish some guidance on MSDN around using workspaces. To date, it has been one of the biggest points of confusion for users that are new to TFS, so we made a point to create new topics with those points of confusion in mind. While we’re still working on the final guidance to be published, I wanted to post a few pieces of guidance I give to people when they’re setting up their workspace.
When creating mappings for your workspace, keep the following points in mind:
- Map high enough (that is, closest to the root, $/) to ensure that you’re not updating your mappings every time a new piece of code is added.
- Map low enough to prevent downloading things you don’t need to do your development work or to build your code.
- Keep your mappings simple – the fewer the better. Only add complexity if it is necessary.
Balancing each of these things is something that is really only possible when the details of the specific projects are known. There are some general best practices that may also be useful when creating a workspace:
- Mapping at the Team Project level is a common approach, and may be a good idea if you only work in one Team Project. Team Projects and workspaces are both tools to provide isolation, so a 1:1 mapping makes sense.
- One branch per workspace is a good practice to isolate changes that don’t logically go together. For example, you probably don’t want to see pending changes from your production branch shown along side your changes for your development branch.
- Using multiple workspaces is a great way to work effectively if you work on multiple projects in parallel and task switch often.
Hopefully that will provide some help to users that are new to TFS until we have better guidance on MSDN.