背景
根据 Visual Studio ALM Rangers 的说法，在 TFS 2012 中有两种主要的资源共享方法（例如，在许多独立产品中使用的公共库）：
- 工作区映射，设置工作区，使它们指向每个所需库和产品的适当版本。
- 共享文件夹，使用分支/合并获取和更新共享资源
乍一看，共享文件夹似乎是可行的方法，但我正在与之合作的一个客户在 Starteam 中使用这种方法遇到了很多问题，并且不愿意在 TFS 中再次尝试。我目前正在协助客户从 Starteam 迁移到 TFS。
我列出了每种方法的优缺点，但我不确定我是否遗漏了什么。
工作区映射：
- 易于设置和理解
- 易于测试多个产品中的库更改
- 轻松获取库中的最新更改，并将更改提交到库
- 没有可追溯性，或者至少可追溯性较低，例如，如果在产品 A 中引入了库中的更改，如何跟踪产品 B 中的更改
- 库中的更改可能会以不受控制的方式影响产品
- 构建变得更加复杂
- 每个用户必须单独设置他/她的工作区（但 TFS 2012 Power Tools 中有工作区模板）
文件夹映射：
- 所需的一切都在给定的分支中配置
- 产品与分支之间的隔离
- 构建被简化
- 对变更的更多控制
- 需要更多磁盘空间
- 需要以分支/合并和设置分支的形式进行更多管理
一个特殊的问题是如何测试几种产品中的库更改。据我了解，这需要在产品 A 中进行测试，然后反向集成到库并正向集成到产品 B，然后测试该产品等等。
结论和最后一个问题
客户已在 Starteam 中成功使用类似于工作区映射的东西 10 年，并计划在 TFS 中继续使用这种方法。尽管他们在跟踪影响多个产品的库更改方面存在问题。
他们担心文件夹共享会变得混乱和复杂。
我的问题是，我是否遗漏了上面列表中的某些内容？组织为什么不应该使用工作区映射，或者为什么他们应该使用文件夹共享，还有更多的理由吗？