问题标签 [tfs]

我们正在使用 TFS 2008 进行项目管理，我正在寻找一种方法来在 tfs 中将较小的任务汇总为较大的任务。我们的工作流程是这样的：

1. 我创建了一个新的大型工作项，例如“实施网页 X”并将其分配给我的开发人员（我们称他为 Brad）
2. 布拉德接到任务。现在他以前从未设计过“网页 X”，也不知道整个事情需要多长时间才能实现。然而，他过去也做过类似的页面......所以布拉德接受了大任务并将其分成四到五个他可以估计的小任务。
3. Brad 完成了他的五项新任务，并估算了每项任务需要多长时间。甚至其中一些任务比 8 小时的工作还要长，所以他继续将任务分解成足够小的部分，他相信他可以准确地估算出实施新网页需要多长时间。
4. Brad 现在有一个很棒的任务列表，其中包含每项任务需要多长时间的实际估计。我可以使用这些数据并计算出实现这个新页面需要多长时间。

在经历了所有这些之后，我们失去了整体的“主要任务”。我正在寻找一个工作流，它可以让 Brad 和我自己轻松引用主任务，并传达所有这些子任务都属于更大的主任务。

关于如何实现这样的工作流程的任何想法，或者关于如何处理 tfs 中的任务汇总的更好建议？

有没有人使用 TFS 的 API 来同步不同类型的存储库？我有一个 SVN 存储库，我想与 TFS 存储库同步。更准确地说，我只想偶尔（每晚）从 SVN 获取最新的所有内容，并将其作为最新版本转储到 TFS。

有什么建议吗？

在 TFS 中的一个“项目”下，我们有多个产品。这是因为对我们来说，一个项目就是一个业务单元，他们每个人都可以拥有我们为他们开发的许多应用程序。每个人都有自己的源代码控制文件夹（在 TFS 项目下），每个人都有自己的 TeamBuild 设置。我遇到的问题是，每当构建运行时，为其生成的报告包含与 TFS 项目关联的所有变更集的列表；即使其中许多是针对不同产品的，并且实际上引用的代码并未在该构建期间编译或构建。

有谁知道如何让 TFS 仅在其报告中包含与 TeamBuild 中正在构建的实际 VisualStudio 项目相关联的变更集？

我一直在谷歌上搜索如何使用 C# 使用 TFS API 移动文件。这个想法是有一个文件夹，开发人员在其中放置数据库升级脚本，构建过程进入该文件夹会创建一个构建脚本，并将文件夹中的所有文件移动到具有我们刚刚创建的数据库构建版本的新文件夹。

我找不到任何关于在 TFS 中以编程方式移动文件的参考...（除了 cmd 命令行）

有人知道通过 c# 学习 TFS 源控制文件操作的良好指南/msdn 起点吗？

We have built a custom application, for internal use, that accesses TFS. We use the Microsoft libraries for this (e.g Microsoft.TeamFoundation.dll).

When this application is deployed to PCs that already have Team Explorer or VS installed, everything is fine. When it’s deployed to PCs that don’t have this installed, it fails.

We include all the required DLLs, but the error we get is “Common Language Runtime detected and invalid program”. The error occurs on the moderately innocuous line:

Interestingly the popular TFSAdmin tool (when you drop in the required DLLs to the exe directory) gives the same error.

I also note that many other custom applications that access TFS (e.g. http://hinshelwood.com/tfsstickybuddy.aspx) also require Team Explorer or VS to be installed to work.

Clearly the DLLs are not enough and there is some magic that happens when these installs occur. Anyone know what it is? Anyone know how to make the magic happen?

给定一个非常基本的源代码树结构，如下所示：

以及一个反映了这一点的环境（开发、QA、登台和生产服务器）——你们都如何管理自动或手动代码提升？您是否在所有阶段都使用 CI 服务器进行构建和推广？开发人员的 CI 构建始终使用的二进制文件？其他混血儿？

我一直在思考几个想法。第一个是每次升级都会执行获取最新、构建，然后将构建的输出推送到正确的服务器。第二个是在某些时候 - QA 或 Staging - 被提升的二进制文件将与复制到其他阶段的完全相同。第三是为已部署的二进制文件保留一个二级源代码树，它会自动与代码升级同步移动。还有其他想法或想法吗？

在使用 TFS 作为源代码控制的 Visual Studio 中，当我查看历史记录并双击一个 cs 文件时，该文件会加载到记事本中。如何将应用程序更改为记事本++？

我还希望文件的操作系统默认应用程序仍然是 Visual Studio

我们目前在工作中同时使用 Visual Source Safe 和 Team Foundation Server（VSS 用于旧项目，TFS 用于当前或新项目）。

我们一直在每次构建的源代码控制中使用标签。在 VSS 中，如果您选择查看文件历史记录，您可以包含标签。在 TFS 中，我找不到将标签包含在历史窗口中的选项。

由于支持或管理层问我的最常见问题之一是“我们修复/添加/删除/更改 xxxx 的版本是什么？”，我一直依赖历史中显示的构建标签。

我可以让标签显示在文件历史记录中吗？

我无法让 Team Build 执行我的 MbUnit 单元测试。我尝试编辑 TFSBuild.proj 并添加了以下部分：

但我还没有让测试运行。

您可以通过“自定义路径”策略限制“签入策略”规则。但是“签入说明”选项卡似乎不适合同一个系统。为什么“入住记录”不只是另一个“入住政策”？

我正在使用 Team Foundation Server 2008 SP1