tfs - 您可以在 TFS 中使用多个工作文件夹吗？

Question

在工作区只有一个工作文件夹的项目中，我的构建脚本运行良好。现在我正在处理一个需要 2 个工作文件夹的新项目，我之前脚本的所有 checkout 和 checkin 命令都失败了，没有找到任何文件。

显然，我不理解这里工作区实现的关键部分......我有一个依赖于其他项目的项目，第二个工作文件夹基本上是一个 3rd 方文件夹，其中引用了各种已发布的 DLL 和头文件编译我的项目所需的文件。有 2 个事件文件夹，本地文件夹是:

$(SourceDir)\TEAM-MAIN\Address Finalizer$(SourceDir)\TEAM-MAIN\HH-CAHPS Project\MAINLINE\3rd Party

The built code works fine, but the custom AfterGet fails on the following entry:

<!-- Check out all of the assemblyInfo files -->
<Exec Command="$(TfCommand) checkout AssemblyInfo.cs /recursive"
      WorkingDirectory="$(MSBuildProjectDirectory)\..\sources"
      ContinueOnError="false"/>

如果我有一个工作文件夹并将源移动到足够高的位置以获取所有需要的文件，该项目当然可以工作，但我不想通过 43 个其他项目来做我想做的事情，让我们一起捣乱他们的汇编文件...

我也试过:

<!-- Check out all of the assemblyInfo files -->
<Exec Command="$(TfCommand) checkout AssemblyInfo.cs /recursive"
      WorkingDirectory="$(SolutionRoot)"
      ContinueOnError="false"/>

同样的问题，找不到任何程序集文件......我检查了构建日志，我肯定会在构建阶段看到程序集文件 checkout ......

任务“获取”
获取 TeamFoundationServerUrl="http://pgpd-team01:8080/"BuildUri="vstfs:///Build/Build/1430"Force=True Overwrite=False PopulateOutput=False Preview=False Recursive=True Version="C7564"工作区="SBN01P-TFS03_61"
<剪辑>
获取 C:\Users\tfsservice\AppData\Local\Temp\InfoTurn\Address Finalizer\Sources\Address Finalizer\Address Finalizer\Properties\AssemblyInfo.cs;C7525。

如果有人有任何想法或可以将我指向一些文章以更好地解释多个工作文件夹的工作原理，我将不胜感激。

一些构建变量的值:

MSBuildProjectDirectory: C:\Users\tfsservice\AppData\Local\Temp\InfoTurn\Address Finalizer\BuildType

SolutionRoot: C:\Users\tfsservice\AppData\Local\Temp\InfoTurn\Address Finalizer\Sources

为了提供更多信息，我添加了以下命令:


<执行
Command='$(TfCommand) 工作文件夹'
WorkingDirectory="$(SolutionRoot)\TEAM-MAIN\Address Finalizer"/>

结果是:

任务“执行”
命令:
“C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\..\tf.exe”工作文件夹
================================================== ==============================
工作区:SBN01P-TFS03_61 (tfsservice)
服务器:http://pgpd-team01:8080/
$/InfoTurn/TEAM-MAIN/Address Finalizer: C:\Users\tfsservice\AppData\Local\Temp\InfoTurn\Address Finalizer\Sources\TEAM-MAIN\Address Finalizer
$/InfoTurn/TEAM-MAIN/HH-CAHPS Project/MAINLINE/3rd Party: C:\Users\tfsservice\AppData\Local\Temp\InfoTurn\Address Finalizer\Sources\TEAM-MAIN\HH-CAHPS Project\MAINLINE\3rd聚会

我发现以下工作目录将起作用:

WorkingDirectory="$(SolutionRoot)\TEAM-MAIN\Address Finalizer"

但是以下两个没有，请注意，第二个是我的第二个工作文件夹:

工作目录="$(SolutionRoot)"
WorkingDirectory="$(SolutionRoot)\TEAM-MAIN\HH-CAHPS Project\MAINLINE\3rd Party"

我为标签任务得到的错误是最有用的:

使用程序集“C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.Build.Tasks.VersionControl.dll”中的“标签”任务。
任务“标签”
标签 TeamFoundationServerUrl="http://pgpd-team01:8080/"BuildUri="vstfs:///Build/Build/1507"Name="Address Finalizer 2.0.1 Build 039"Recursive=True Comments="Automated build: Address Finalizer 2.0.1 Build 039"Version="W"Child="replace"Files="C:\Users\tfsservice\AppData\Local\Temp\InfoTurn\Address Finalizer\Sources"
C:\Users\tfsservice\AppData\Local\Temp\InfoTurn\Address Finalizer\BuildType\TFSBuild.proj(310,5,310,5):错误:错误:无法确定工作区。

结帐的实际错误(无用)是:

任务“执行”
命令:
“C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\..\tf.exe” checkout AssemblyInfo.cs/recursive
在您的工作区中的 C:\Users\tfsservice\AppData\Local\Temp\InfoTurn\Address Finalizer\Sources\AssemblyInfo.cs 中找不到匹配的项目。
C:\Users\tfsservice\AppData\Local\Temp\InfoTurn\Address Finalizer\BuildType\TFSBuild.proj(280,5): 错误 MSB3073: 命令 ""C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\..\tf.exe"checkout AssemblyInfo.cs/recursive"以代码 1 退出。

Answer 1

可以同时使用不相交的工作区映射 + 递归。你只需要小心。

这将获取 Foo & Bar 中的所有 C# 文件:

$/project/dir1/foo -> c:\code\foo
$/project/dir2/bar -> c:\code\bar

tf get c:\code\*.cs -recursive

这通常会获取 Foo & Bar 下的所有内容，但如果工作目录无法明确解析为工作区，则会失败:

$/project/foo -> c:\code1\foo
$/project/bar -> c:\code2\bar

tf get $/project/* -recursive

这可能会起作用(与上面的警告相同)，但它可能不会达到您的预期!

$/project/foo -> c:\code1\foo
$/project/bar -> c:\code2\bar

tf get c:\code* -recursive

还有更多的变化；该行为取决于您的工作区是如何定义的，以及同一台机器上是否存在具有类似本地路径的其他工作区。你能准确地说出你的构建定义吗？您是否可以添加一些调试语句来验证执行目标时 $(SolutionRoot) 和其他 MSBuild 属性究竟等于什么？

/编辑/

正如我所说，不相交的映射 + 递归很难做到正确。事实证明，行为不仅因文件规范与工作区定义的微妙细节而异，而且因命令而异!与我的第一个示例不同，这失败了:

$/project/dir1/foo -> c:\code\foo
$/project/dir2/bar -> c:\code\bar

tf checkout c:\code\*.cs -recursive

还糊涂？我是，我在 TFS 团队工作了几年!

让我从各种评论线程中总结我的建议:

super 小心。在将任何内容放入 msbuild 脚本之前，登录到构建机器并测试它!交互式测试时，您将获得更好的错误消息和更快的反馈。这很重要，因为您尝试做的事情非常脆弱。从表面上看你的脚本，这里有一些更正可以帮助你入门:

Checkout 任务应使用服务器路径以获得最佳结果。修复后，您可以从 $(SolutionRoot)\TEAM-MAIN\Address Finalizer 或 $(SolutionRoot)\TEAM-MAIN\HH-CAHPS Project\MAINLINE\3rd Party 运行它，没有区别。 [不是普通的旧 $(SolutionRoot)，不幸的是——如上所示，Checkout 不像 Get 那样智能] 它似乎在使用本地 itemspec 时从 Address Finalizer 工作的原因是因为您实际上在该本地目录下有一些匹配的文件.大概您在 3rd Party 下没有任何 AssemblyInfo.cs 文件。相比之下，使用诸如 $/InfoTurn/TEAM-MAIN/AssemblyInfo.cs 之类的服务器路径将扩大范围，以便 TFS 搜索所有 TEAM-MAIN 以查找要 checkout 的匹配文件。您仍然必须从明确确定工作区的工作目录中运行它——或者指定/server 和/workspace 选项——以便 TFS 可以将查询限制为工作区中的实际项目，并知道将它们 check out 给谁.

同样，您编写的 Label 任务需要使用服务器路径 + 从直接映射的文件夹运行。或者您可以使用完全限定的版本规范 (Wwsname;domain\wsowner) 而不是缩写 (W)。

更好 ，首先不要使用不相交的工作区。查看所有被映射的本地路径:它们的共同祖先本身应该是一个映射文件夹。否则 (a) 从那里运行的命令将不明确，需要额外的参数，和/或根本不起作用 (b) 从单独映射的子文件夹运行的命令不会在整个工作区中查询 [除非您使用服务器路径]。为了避免这一切，选择一个映射作为“根”，然后确保所有后续映射都指向它下面的某个地方。一旦你建立了一个统一的根，事情就会变得容易得多。从内部任何地方运行的 tf 命令将更可预测地运行(对于新手和专家!)。有多种方法可以设置满足您目标的统一工作区:

切换回一个大映射，然后隐藏您不想要的文件夹。请注意，您可以在 cloaks 下创建正映射(例如 cloak $/InfoTurn/TEAM-MAIN/HH-CAHPS Project，同时仍然映射 $/InfoTurn/TEAM-MAIN/HH-CAHPS Project/MAINLINE/3rd Party)。这为您留下了一个漂亮干净的工作区，并且没有时髦的副作用。缺点是涉及的工作量大。如果有大量文件夹，您可以使用脚本来创建斗篷，但即便如此，仍然存在在添加新文件夹或重命名现有文件夹时使它们保持最新的问题。

查找作为当前映射的父文件夹的文件夹，并为其创建一级映射。例如，您可以创建一个一级映射 $/InfoTurn/TEAM-MAIN/* ->
$(SolutionRoot)\TEAM-MAIN。这将拉下 TEAM-MAIN 的所有直接子级，但不会进行更深的递归，除了您已经使用完全递归添加的两个文件夹。缺点是需要下载和标记一些额外的文件。

更改您当前的映射，以便一个文件夹映射到另一个文件夹下。例如，您可以映射 $/InfoTurn/TEAM-MAIN/Address Finalizer -> $(SolutionRoot) 和 $/InfoTurn/TEAM-MAIN/HH-CAHPS Project/MAINLINE/3rd Party -> $(SolutionRoot)\3rd Party。现在 $(SolutionRoot) 是您需要的所有代码的统一根。此解决方案的问题在于，它可能会破坏依赖于在构建配置和其他尝试使用时髦映射构建 Address Finalizer 的其他配置之间保持恒定的相对路径的任何 makefile。

将您的 3rd Party 文件夹移动到源代码控制结构中更自然的位置。毕竟，您可能不是在 TEAM-MAIN 中唯一需要引用 3rd Party 组件的人。如果你们都同意将共享资源保留在根目录并适本地制作你的 makefile，那么大部分关于将深层路径映射到工作区的问题就会消失。

更好的是 , 不要在构建过程中 checkout / checkin 文件。严重地。考虑到所有可能的边缘情况，人类易于处理的常见情况(例如锁定、版本冲突)是自动化的噩梦。如果你曾经尝试使用持续集成，上帝会帮助你......同时，当你调试我真的没有看到任何好处的功能时，你所有重要的构建都被破坏了。反而:

将所有系统范围的程序集信息(包括构建编号)合并到一个 AssemblyInfo.cs 文件中。

从每个项目导入的公共(public) MSBuild *.targets 文件中引用此 C# 文件。 (如果您还没有这样做的话，这是重构项目级任务的好机会)。

让 Team Build 根据需要修改此 C# 文件。例如。您可以在 CoreCompile 任务之前随时填写内部版本号。请注意，我们只是覆盖磁盘上的内容，而不涉及源代码控制。

如果您希望您的桌面版本也具有增量编号(我个人不明白这一点)，请将类似的任务添加到您的公共(public) *.targets 文件中，并使用将其从 Team Builds 中排除的条件。