我们正在转向TFS 2010（来自PVCS）进行源控制和工作项跟踪
根据我的理解，你应该对每个TFS项目进行源代码控制，所有项目解决方案等都需要构建。
这适用于新的.NET解决方案/项目，但我们有大量遗留的 Delphi 6 项目，我们希望将共享的源库移植到TFS for sources控制和建立。这就是我们如何管理多个想要在它们之间查找一组特定源文件的TFS项目，这是我的问题。
历史上，对于PVCS，我们已经为每个解决方案（比如A＆amp; B）提供了项目，并且为共同的源代码（比如说C）提供了一个单独的项目。用户会得到C然后在磁盘上获得A或B（根据需要检出），这将像这样：
$\Projects\C
$\Projects\B
但B＆amp; C是单独的PVCS档案。
现在快速将TFS 2010作为我们的ALM解决方案......
如果我们创建一个包含公共代码（C）的源存储库的TFS项目（1），那么项目显然可以访问它（假设TFS项目也包含解决方案A），一切都很好。
我们现在创建一个新的TFS项目（2），在其中制作解决方案B. Beacuse解决方案B与解决方案A截然不同我们没有理由共享TFS项目1的源代码控制，因此我们创建了一个新的源代码库而不是分支从现在开始，我们发现解决方案B需要从C（1）中访问一些常见文件。糟糕！
问题是这个;我可以执行一些源代码控制wizzardry，它允许我在2的soruce控件中添加一个文件夹，这是一个（用于窃取文件系统术语）符号链接到1的公共代码C的源代码控制中吗？
修改
我应该指出这是所有遗留代码，共享源代码库（C）只是共享源代码，它不会构建到我们可以简单地添加到A或B的库或其他二进制文件中。
答案 0 :(得分：5)
在TFS 2010中，您可能知道，他们引入了项目集（PC）的概念。每个项目集合都是团队项目（TP）的汇总。每个 PC 都存储在一个单独的数据库中，VCS存储在数据库中。
这意味着每台PC有一个VCS存储库，而不是TP。每个TP（默认情况下）是每个VCS中的根文件夹（即TP1将位于$ / Prj1，TP2可能位于4 / Prj2等）
还有一点是，您不希望每个TP都有一个解决方案。将TP视为一套产品，并将其作为其中一部分的解决方案。
根据Visual Source Safe的符号链接在TFS中不再存在，我不确定您是否需要它们。在一个解决方案和另一个解决方案的源代码之间创建依赖关系并不是一个好习惯。
我建议您做的是，您的代码库中的每个解决方案仅依赖于自己的代码，和其他解决方案的二进制交付
如果Sln_A依赖于Common_Sln，您将构建Common_Sln，并将其二进制文件从放置位置作为 Get 的一部分。然后，添加二进制文件作为引用。
这将解决您的问题，还有一个额外的好处，即转换紧密耦合，其中依赖关系可能会破坏您的依赖解决方案的构建，进入您不会更改或升级依赖关系的情况，直到它们准备就绪和
这有助于解决您的问题吗？这就是我对我咨询的项目的处理方式。 HTH，
阿萨弗。