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