TFS是我曾经不幸不得不使用的最不直观的版本控制系统之一。就原始特性列表和功能而言，与 OnTime（和其他类似系统）相比，它可能具有许多“要点”优势，但关键因素是它是否适合您的工作流程。
我对TFS的经验是，您将需要适应TFS的工作方式，因为使TFS适应您的工作方式是不可能的或难以证明的。
我们最近审查了一些可能的替代方案，以取代由 SVN 和手动错误跟踪系统（Excel 电子表格）组成的系统。准时进行了评估，但被认为过于昂贵和复杂。
最后，我们选择继续使用 SVN，但彻底修改（简化）了我们的存储库结构，并选择将 SVN 与 FogBugz 问题跟踪系统结合起来。这两个系统之间的集成是相当初级的“开箱即用”，但我们只需要一点点努力就可以实现我们想要的更接近的集成水平。肯定比我以前参与TFS推出的经验要少得多。
我们的 SVN/FogBugz 系统现在也与 FinalBuilder 构建自动化套件集成。
结果是一个系统不仅完美地适合我们的工作实践（因为我们设计了系统整合的方法来实现这一点），而且随着我们工作实践的发展，它也可以无限适应。
我认为这实际上取决于您团队的规模，以及您希望从源代码控制中获得什么。
我将 bugzilla 与 Perforce 结合使用了几年，发现在一个非常小的团队（2-3 人）中工作时，两者都非常擅长自己的个人事情，但是由于它们之间缺乏集成和从一些需要时间来适应的小特质。
我最近换了一份广泛使用 TFS 的新工作。这家公司有 4 个主要团队，每个团队有 10-12 名开发人员，在该级别以下划分为更多的项目团队，正是在这种环境下，TFS 真正在 imo 中大放异彩。在我看来，它最大的优点是：
1) 与 Visual Studio 的集成 - 这不仅仅是打开更少窗口的情况，而且确实可以加快速度并使您的生活更轻松。诸如 VS 在您工作时自动为您检出文件（不会因无锁编辑而导致意外检出问题），能够同步本地 + TF 构建，能够快速将本地版本与以前的版本进行比较……是的，您可以获得3rd 方插件集成，但没有达到这个级别并且具有相同的稳定性。
2) 通信功能 - 简单的东西，如与 Live Messenger 的集成（前提是您正确配置 TFS）非常适合大型团队。我们使用 WLM 在办公室内进行交流和协作，因为它比每次您需要快速提问时都快到别人那里来。
3) 将构建/更改列表链接到任务 - 是的，其他 SCM 会这样做，但它只是以一种非常好的、集成的方式完成的。我想这对 TFS 来说没什么特别的，但我个人喜欢它跟踪这个的方式。
4）易于合并/无锁编辑。我有使用其他一些合并工具的经验，并且 TFS 工作得很好，使得并发编辑后的合并非常简单。它在这方面与 perforce 非常相似，但也有一个通常非常有效的自动合并工具，我将其用于我知道不会对其他开发人员正在进行的编辑造成任何潜在问题的微小编辑。
5）自动构建/构建管理。使用包含 20-30 个相互依赖的项目的大型解决方案，这是天赐之物。我们将它设置为每 20 分钟排队一次构建，如果发生了变化，并且当发生变化时，它会列在历史日志中......所以当您需要更新本地库时很容易看到。
除了构建管理之外，我没有任何配置它的经验，但我听说这是 TFS 最糟糕的部分..让一切正常运行有点痛苦。
因此，将其转化为商业案例。我想说，如果您是拥有大型/多个团队的 Microsoft 软件公司，那么您将看到上述功能所带来的时间节省和生产力提升是值得投资的在设置它。它在大多数情况下免费使用，因为您可能会订阅 MSDN（可能有一些 CAL 问题，但我不确定），因此您最大的成本将是用户培训和配置。
首先，我建议您考虑一下您最关心的问题，以及通过推出 TFS来解决的问题是什么。
在版本控制方面，我推荐 Martin Fowler 关于版本控制工具的博客文章和版本控制系统调查的后续结果。诚然，这可能是并且是对该主题的主观看法，但似乎很受欢迎。与其他版本控制系统相比，TFS 明显松了。
我目前使用 TFS2008，我们已经从 SourceSafe 和 IBM ClearCase/ClearQuest 迁移，毫无疑问，TFS 比以前的任何工具都要好，但它仍然存在严重的缺点，新版本只能部分解决这些问题。
解决您提出的个别问题：
关于 TFS 的优势，我可能会提到
鉴于推出完整 TFS 安装的巨大成本，我真的会考虑这个解决方案会给您带来什么真正的商业利益，而其他人没有。
不关心 TFS，但 OnTime 的 UI 有点不直观。我也不喜欢你有不同的错误和任务字段。当然，您始终可以添加自己的字段，但默认布局应该可以使用。
即使它是一项任务，我们也只使用“错误”。
我并不是说它是一个糟糕的产品，但如果 TFS 现在有一个更好的错误跟踪 UI（4 年前我不得不使用它并且讨厌它时它还没有），那么这将是 TFS 的一个论点。
很遗憾听到您想摆脱 SVN。这是一个艰难的决定。
我不确定 Axios OnTime 的许可，但如果您订阅了 MSDN，则无需额外费用。请参阅此处的博客文章
我一直将 TFS 2008 用于版本控制，虽然它是 VSS 的一个很好的升级，但我们正在努力做的一些事情并不完全符合预期。也就是说，我编写了一个快速的小型网络应用程序来填补这些空白。使用 API 进行开发非常容易，并且有很多插件可以帮助完成特定任务。
可能不是您想听到的答案，但我会竭尽全力针对TFS 提出商业案例。
无论如何，我的一般建议是自己（或在一个小团队中）在一些非常小但真实的项目中尝试一下——也许你需要一些一次性的工具，可以丢弃或容易的代码迁移到另一个系统，因为它很小。没有什么比实际使用系统更好的了！
我使用过 OnTime 和 Subversion。我没有将 TFS 用作错误跟踪器，但我将它用于源代码控制。它的源代码控制部分基本上仍然是糟糕的旧Visual SourceSafe。如果您当前正在使用 Subversion，您将在需要重命名文件时发誓，或者，天堂禁止，删除文件然后创建一个具有相同名称的文件 - 更不用说任何分支或合并。很难在帖子中表达它作为源代码控制系统是多么原始和脆弱——这就是你真正必须使用它的原因。当您发现自己陷入无法签入或删除的文件以及一些无意义的错误时，您会明白我的意思。并不是说 Subversion 是完美的——但它比 VSS 早了十年！
TFS 的工作流部分，我只是简单地玩过，对我来说似乎非常“沉重”。也就是说，它确实将用户限制在该工作流程中，并且需要许多通常不必要的步骤。这些东西可以提供帮助，但它也很容易成为障碍。一个好的系统会在需要时提供工作流程，但允许您在它妨碍工作时绕过它。当我们使用 OnTime 时，我们发现即使是其相对不显眼的工作流程也往往比它的价值更麻烦。当然，这一切都取决于您的具体情况。您现在如何使用 OnTime 工作流程，您希望从 OnTime 不提供的 TFS 中得到什么？
也可以使用 Subversion 将变更集链接到错误。它支持一些扩展机制——我不记得细节了，但 FogBugz 使用它（我们在 OnTime 之后切换到它）。可以通过在构建脚本中添加一个简单的 svn tag 命令来链接到构建。Visual Studio 集成可以使用VisualSVN完成。
成本也是 TFS 的一个巨大缺点。它的功能非常昂贵，尤其是当您考虑到它的功能时。是的，如果您无论如何都必须为每个开发人员订阅 MSDN ，它是“免费的” ——但是在没有 TFS 的情况下您是否必须这样做？颠覆是免费的，句号。OnTime 和 FogBugz 的价格要合理得多。
我强烈建议不要使用 TFS。我曾经试图从一个崩溃的实例中恢复源代码，但几天后我放弃了，所以源代码丢失了（=它没有做 VCS 应该做的一件事）。当然，我可能做错了什么，但是当恢复指南长达两英里时，要让所有事情都正确并不容易，而且它确实应该很少发生，以至于没有人有经验。
现在我使用 Subversion/Trac，它可以完成工作（与 TFS 相比，在 Trac 中自定义工作流程非常简单，但并不有趣）。
暂时避免使用 TFS！
我会坚持使用 SVN + FinalBuilder，然后在 FogBugz 或 CounterSoft Gemini 之间进行选择。