从另一个 TFS 项目链接 TFS 源代码管理文件夹
我们正在转向 TFS 2010（从 PVCS）进行源代码控制和工作项跟踪
据我了解，您应该将每个 TFS 项目的项目解决方案等需要构建的所有内容都置于源代码控制之下。
这对于新的 .NET 解决方案/项目来说没问题，但我们有大量遗留 Delphi 6 项目，其中包含共享源库，我们希望将其移植到 TFS 中以进行源代码控制和构建。我的问题是我们如何管理多个 TFS 项目，这些项目希望在它们之间共享一组特定的源文件。
从历史上看，对于 PVCS，我们为每个解决方案都有项目（例如 A 和 B），以及一个针对公共源代码的单独项目（例如 C）。用户将获得 C，然后在磁盘上获得 A 或 B（根据需要检出），这将表现为如下所示
$\Projects\C
$\Projects\B
： C 是单独的 PVCS 档案。
现在快进到使用 TFS 2010 作为我们的 ALM 解决方案...
如果我们创建一个 TFS 项目 (1)，其中包含公共代码 (C) 的源存储库，那么该项目显然可以访问它（假设 TFS 项目也包含溶液 A) 并且一切都很好。
我们现在创建一个新的 TFS 项目 (2)，在其中创建解决方案 B。由于解决方案 B 与解决方案 A 截然不同，我们没有理由共享 TFS 项目 1 的源代码控制，因此我们创建了一个新的源存储库，而不是从 1 分支。现在稍后我们发现解决方案 B 需要从 C 访问一些常见文件（在 1 中）。哎呀！
问题是这样的；我可以执行一些源代码控制魔法，让我在 2 的源代码控制中添加一个文件夹，该文件夹是公共代码 C 的（窃取文件系统术语）符号链接到 1 的源代码控制中吗？
编辑
我应该指出，这都是遗留代码，共享源库 (C) 只是共享源，它不会构建到库或其他二进制文件中，我们可以简单地将其添加到 A 或 B。
We are moving to TFS 2010 (from PVCS) for source control and work item tracking
As I understand it you should have under source control for each TFS project everything that projects solutions, etc. need to build.
This OK for new .NET solutions/projects, but we have a large collection of legacy Delphi 6 projects with shared source libraries we want to port into TFS for source control and build. It is how we manage multiple TFS projects that want to sare a specific set of source files between them that is my problem here.
Historically with PVCS we have had projects for each solution (say A & B), and a seperate project for common source code (say C). Users would get C then get either A or B (checking out as required) on disk this would maifest as something like this:
$\Projects\C
$\Projects\B
But B & C are seperate PVCS archives.
Now fast forward to life with TFS 2010 as our ALM solution...
If we create a TFS project (1) that contains the source repository for the common code (C), that projecs can obviously access it (lets say the TFS project also contains the solution A) and all is good.
We now create a new TFS project (2) in which to make solution B. Beacuse solution B is wildy different to solution A we had no reason to share TFS project 1's source control so we made a new source repository rather than branching from 1. Now later on we discover a need for solution B to access some common files from C (in 1). Oops!
The question is this; can I perform some source control wizzardry that lets me add a folder in the 2's soruce control that is a (to steal a file system term) symbolic link into 1's source control for the common code C?
Edit
I should point out this is all legacy code and the shared source library (C) is just that shared source it does not build into a library or other binary we could simply add to A or B.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能知道，在 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 的一部分。然后，添加二进制文件作为引用。
这将解决您的问题，还有一个额外的好处，即将紧密耦合（依赖项可能会破坏您的依赖解决方案的构建）转变为一种情况，即在依赖项准备好之前您不会更改或升级依赖项并且已经为他们做好了准备。
这有助于解决您的问题吗？这就是我对我咨询的项目的做法。
哈特哈，
阿萨夫。
In TFS 2010, as you may know, they introduced the concept of a project collection (PC). Each project collection is an aggregate for team projects (TP). Each PC is stored in a separate database, and the VCS is stored in the database.
This means that there is one VCS repository per PC, not TP. Each TP is (by default) the root folder in each VCS (i.e. TP1 will be at $/Prj1, TP2 might be at 4/Prj2, etc.)
One more point is that you do not want to have one solution per TP. Think of a TP as a suite of products, and a solution as a part of that.
Symbolic links, as per Visual Source Safe, no longer exist in TFS, and I'm not sure you need them. It is not considered a good practice to create a dependency between one solution and the source code of another solution.
What I suggest you do, is have each solution in your codebase depend only on its own code, and on other solutions' binary deliveries.
What will happen is that if Sln_A depends on Common_Sln, you will build Common_Sln, and bring its binaries from the drop location as part of your Get. Then, add the binaries as references.
This will solve your problem, with the added benefit of transforming a tight coupling where a dependency may break your dependent solution's build, into a situation where you do not change or upgrade your dependencies until they are ready and you are ready for them.
Does this help solve your problem? This is how I do this with the projects I consult on.
HTH,
Assaf.