Workspaces in Team Build
Workspace represents the client side view of the source control repository. When you create new build type using wizard, you have the option of selecting the template workspace. This implies that you want to have the same view of repository as defined in the template workspace. There is one problem with this approach. Each build type is associated with a team project but the workspace can span across multiple team projects. It is possible that user might have permission to work on current team project only. In that scenario, it will not be nice for us show the user view across different team projects. Moreover we started the design with the assumption that team build will work with one team project at a time. Fortunately it is possible to build sources with multiple team projects (refer this blog for more details) but still there are some issues around it and we might/need to have a better story in next version. Anyway in the current design we have introduced a filter at the client. The filter will filter all the server mappings based on active (current) team project and ignore all the mappings belonging to other team projects. Then we serialize these mappings in a file called “WorkspaceMapping.xml” and store it along with TfsBuild.proj file. Please note that only the server paths (of the xml file) are used and the local paths are ignored.
The story is quite simple on the build machine. The createworkspace task will deserialize the “WorkspaceMapping.xml” file and will use the server mappings only. It will evaluate the common maximum server path (more details about it in next post) and uses it to calculate the local mappings on build machine. Thus we just need to know the right workspace name and magically team build will translate the relevant mappings for build machine.
Another interesting point is that end user can manually edit the “WorkspaceMapping.xml” file and include additional mappings to customize the build process. However do note that in beta3 bits, if you put mappings belonging to different team project then the createworkspace task will fail. Moreover if you add additional mappings manually in the xml file then the common maximum server path might change between client and build machine. This might result in build break as the sln/vsmdi files relative path will be broken on the build machine. You might also have to manually edit the TFSBuild.proj file and specify the right path for sln/vsmdi files. Sadly this is quite painful and I would recommend people to avoid it if possible. Hopefully we will have a better support for working across multiple team projects in next version. More in next post …
Also check this interesting post by Anutthara.