Workspace mappings best practices

Recently, I was asked if there are any best practices when defining workspace mapping. While I did not have any ready best practices, after some careful (late evening) thought I came up with several “best” practices that seemed worth sharing.

In ideal world, one would have a single mapping in a workspace. However in most projects single folder will either contain too many items or only part of the files required for specific project development/build.

In the former case, it is possible to cloak the redundant folders and thus optimize the time required to get files (cloaking folders excludes them and all their contents from get operation).

In the latter case, there is no escape but to map several folder in one workspace. Generally, there is no problem (other than managing multiple mappings) with this scenario; but the multiple mappings require certain degree of common sense, as illustrated in the example below. 

Consider the following folder structures:

 $/
   Project1
     Sources
       Common
         Bin

 $/
   Project2
     Sources
       Bin

Let’s suppose the following set of mappings get created in a workspace:

 $/Project1/Sources -> c:\src\Project1 
 $/Project2/Sources/Bin -> c:\src\Project1\Common\Bin 

In generally, this setup is perfectly valid and works fine, but two folders hierarchies above have some common folders between them when mapped; namely, $/Project1/Sources/Common/Bin is implicitly mapped to the same local folder that $/Project2/Sources/Bin is explicitly mapped to.

Can you guess what will happen when “get latest” is performed on that workspace? Let me tell you what will happen (I failed the test myself) – only explicitly mapped folder contents will be retrieved from source control.

That said, here are my top five best practices on workspace mappings

1. Minimize number of mappings in single workspace. The more complexity is there, the more mistakes end users will make. Take that into account when you design state-of-the-art CM process that requires 50 workspace mappings per project

2. Map all related folder in single workspace; do not mix - create another workspace for every related subset of folders. Giving the workspaces descriptive names and making sure the mappings under workspace related to the name will save you a lot of time, especially when you switch between multiple projects daily

3. Cloak sparingly and only when performance is affected. The same complexity rule as in 1 applies. In my experience, cloaking is appropriate only in few cases, and when it is required it is usually a sign of certain problems with folders structure in the source control repository (not to mention that you will have to explain cloaking to end users)

4. When defining multiple mappings to create complex folder structure, make sure the folders with the same name from different mappings are not mapped to the same location. The discussion above is the basis for that rule - do not be afraid to create local hierarchy using mappings, but put some thought into it. I usually use that kind of mappings for external dependencies (and works pretty well), for example

 $\Project\Sources -> c:\src\Project 
 $\ThirdParty\Component\1.1\Bin -> c:\src\Project\Bin\Component 
 $\Infrastructure\Ongoing\Bin -> c:\src\Project\Bin\Infrastructure 

5. If you have more than three mappings per workspace, automate workspace creation.  This one is a topic in its own right and deserves a blog post – but in a nutshell, just consider how are you going to set up workspace mappings on your co-worker machine