建立团队构建类型，请注意定制工作空间

(English version of this post)

在团队浏览器2008中定义团队构建类型时，向导会提供此次构建的默认工作空间，映射到“$/ <team_project_name>” 即团队项目源代码管理根目录。很多时候这个默认设置并非最佳选择。为了让构建更加高效，建议此处修改工作空间，使其“服务器端源代码控制文件夹”仅包含构建需要访问的路径。忽略此处定制而使用默认设置给构建带来的坏处有以下几点（非完全列表）：

1. CoreGet target 默认情况下获取整个工作空间范围的源代码文件。如果工作空间映射范围太大，则CoreGet执行时会造成非必要的文件下载，尤其是整个项目源代码较多，但构建仅涉及其中一小部分时的情况下，默认工作空间映射会浪费更多时间和硬盘空间；

2. CoreLabel target默认情况下将标签设置在整个工作空间范围。然而通常用户希望每次构建仅label构建涉及的源代码文件，而不是整个团队项目范围。

3. GenCheckinNotesUpdateWorkitem target 比较两个标签--一当前构建的，何上次成功构建的--来得到与当前构建相关联的变更集和工作项集合。当CoreLabel 应用于整个团队项目源代码范围，GenCheckinNotesUpdateWorkitem 也会令构建报告中包含整个团队项目范围的变更集和工作项，而其中有些可能与此次构建根本不相关。

我遇到的一个相关实例是，客户希望在代码的一个分支上进行构建，但是发现构建报告竟然涵盖了其他分支上发生的变更集和工作项。导致项目组无法按照分支进行信息追踪。解决方法既是将构建的工作空间限制在目标代码分支上，而不是整个团队项目范围。

产品组的Jim和Buck对此问题进行了详细的解释。在此致谢。