我们应该从svn迁移到Team Foundation Server 2010吗？

Question

我们是6位开发人员，目前使用带有SVN和Visual SVN的Visual Studio 2008 Professional。一旦vs2010发布，我们将从vs2008 pro升级到vs2010 premium。

但是，如果Team Foundation Server在vs2010 premium中包含适当的源代码控制，那么使用它确实有意义。我们喜欢SVN，但更喜欢紧密集成工具。

在互联网上有关SVN与TFS 2010的信息似乎很少。因此我的问题在这里。

编辑：此video看起来非常引人注目。这个营销谈话还是真实的？

谢谢大家的回复！我非常欣赏这一点。多一点背景信息。

这是我们目前的筹码; vs2008 pro，Visual SVN，SVN，Jetbrain Teamcity。我的主要问题是我们使用了来自不同供应商的大量工具，这些工具或多或少地集成在一起。有时更多，大多数更少。至少需要花费大量时间才能正确设置它。

我们目前不使用分支机构，但我们想要。因此，我们必须从头开始设置SVN（我们仔细研究过）。所以让我重新提一下我的问题：我们应该设置SVN还是开始使用TFS？

Answer 1

根据我的经验，TFS作为源控制服务器不是正确的选择。合并速度非常慢，签到程序反直觉，通常以只有管理员可以解锁的锁定文件结束。 SVN更加成熟，灵活，快速。

Answer 2

如果您是微软的商店，那么TFS非常合适。

如果Subversion完成了你需要的一切，你会修复一些没有破坏的东西吗？

你必须有理由改变。

[我在工作中使用TFS，效果很好，问题很少。我在家里使用Subversion，仅仅是因为我需要更少的基础设施]。

更新[2012/05/01]：如果您不是微软的商店，那么Git和mercurial现在将成为首选工具。

Answer 3

似乎有很多人建议改用TFS，我想转向其他方式。

我在上一份工作中从使用SVN转到最近一份工作的TFS。我总结如下：

集成是有吸引力的，没有其他任何东西可以将所有部件集成在一起。权衡的是，每个单独的部分都很糟糕。

更多细节：

源控制系统虽然在服务器上技术上非常好，但是使用起来非常好。文件始终标记为只读，您必须明确检查它们才能编辑它们。除非你在100％的时间内使用visual studio集成，否则这会让你的生活变得糟糕...如果你正在使用visual studio集成，请记住它将所有文件的SCC状态存储在CSPROJ文件中，所以准备好处理偶尔的混乱和失败，因为你把文件添加到TFS，但是visual studio没有意识到这一点（反之亦然）。

错误跟踪系统搜索能力差，搜索量有限，用户界面难以使用。它让我想起了很多旧的访问数据库表单。相比之下，这是一个很好的干净的基于网络的跟踪器，它是白天和黑夜。

总的来说，大部分用户界面的可用性都很差。虽然你可以使用TFS完成许多事情，但它不会很快，你必须点击太多的组合框！

此外，TFS与您的域名紧密集成。如果100％的员工和所有构建/测试机器都在同一个域中，那么这可能很好......但如果你不是，那么这会给你带来一些痛苦。

Answer 4

SVN做源控制。它的默认客户端是命令行，但存在GUI工具。

TFS进行源代码控制，错误/问题跟踪，自动构建，管理员报告，并可以治愈男性模式秃头。它的默认客户端是Visual Studio。

如果所有你想要的是源代码控制，那么SVN可以工作，为什么要改变未破坏的东西。如果你想要的是更紧密地集成到Visual Studio中，那么请查看Ankh或VisualSVN。

如果您想要自动构建，持续集成，签入策略和规则，报告，问题跟踪以及您希望它们都在一个，那么TFS适合您 - 假设您不在Microsoft开发工具之外冒险（通常 - 那里）是其他IDE的插件）。您可以使用其他FOSS工具获得相同的功能，并使用粘性磁带将它们包装在SVN周围，这也是有效的，它不是无缝的，需要更多的投资。

但是，您要将源控制系统与开发生命周期管理工具进行比较。 TFS做源代码控制，但它做得更多。

Answer 5

真的，您应该尝试使用新的测试系统来评估它。很多人讨厌TFS，有些人认为它不适合他们的工作方式。当你不得不开始购买更好的VS版本以获得一旦你上瘾时你想要的附加功能，它就不那么自由了。

网上有一些评论不是MS市场营销人员发现TFS不是自git以来最好的东西。 Martin Fowler的survey非常有趣（在54个回复中，没有人认为它很棒甚至好）。也许他的读者不像大多数开发人员那样热衷于'完整生命周期'开发工具，但是，也许他们和我们其他人一样。类似的评论是可用的 - 包括Forrester Research's piece（我读过：执行摘要，SVN是独立SCM的“获胜”）

所以，仅仅因为TFS现在包含在VS中并没有使它成为最好的。您需要在切换之前正确评估它。

Answer 6

我不得不使用TFS，并且每分钟都讨厌它。它只是让我的方式太过分了，而且远程做任何事都需要永远。但主要是这只是我的非理性仇恨。如果你的六位程序员中有一位和我一样，你就会遇到问题。程序员比工具更重要。

Answer 7

我是一名Java开发人员，但我所有的朋友都是.Net，他们似乎更喜欢SVN和Tortoise。 SVN也得到了开源社区的大力支持。

Answer 8

我认为TFS太棒了。将错误跟踪和源代码控制与Visual Studio完全集成可以节省大量时间。线上协议不是太繁琐，因此它也适用于在需要时通过Internet工作。

还有许多其他功能也很有用，例如团队门户，统计跟踪，跟踪测试历史，捕获测试输出作为错误的一部分（非常方便！）等。

他们还拥有对脚本，自动构建，在Visual Studio外部使用的独立TFS客户端（例如非开发人员）的完整命令行支持，以及与第三方工具（例如Eclipse）的可选集成，用于混合Java /。网店。

主要缺点是价格 - 但如果你负担得起，我认为它是目前最好的系统。

Answer 9

如果您只是将它用于版本控制，请坚持使用SVN。 如果您有Linux / Java解决方案，请坚持使用SVN。 如果您只是MS并且您喜欢使用工作项来进行需求/错误跟踪等（我喜欢），请考虑转移到TFS，但请记住，您需要为CAL预算，以便人们可以访问此信息。 如果您想要隔夜测试/ CI构建，请记住为构建服务器预算额外的VS许可证，因为teambuild（msbuild）无法构建VDProjs，英特尔项目等。

同样...... TFS'似乎'/'似乎'与一些非常基本的东西斗争，例如如何忽略你不想放入存储库的文件，它经常将文件标记为已经更改，diff显示为相同。

Answer 10

这更像是心理问题，而不是技术问题。

至于我的观点，你不应该迁移并保持简单。只有6个开发人员，你将无法获得足够复杂的东西来使用甚至一部分高级TFS2010能力。

VisualSVN是一个很好的工具，可以让你“整合”得足够多。它会得到更好的改善。

Answer 11

虽然this可能会帮助您做出决定;我同意米奇的观点。你必须有充分的理由改变。 SVN比TFS更成熟，更可靠。此外，与SVN的范围相比，TFS主要针对Microsoft应用程序。

Answer 12

我在我的上一个客户端有TFS，现在我的新客户端有颠覆，而且很糟糕。没有搁架是真正的杀手。

我是否在VS 2010中免费提及

Answer 13

我使用过TFS 2010和SVN（使用Tortoise），Mingle，MediaWiki等。

虽然TFS为您提供了与Visual Studio集成的源安全​​风格，但这就是细节结束的地方。 SVN在版本控制方面要好得多，Mingle是一个非常好的协作工具，MediaWiki是一个更好的维基。

如果您需要测试TFS的主要产品作为源代码控制，那么创建几个TFS项目，添加一些更改并尝试恢复到以前的版本。您将需要一个命令提示工具，如果您在遵循劣质的在线说明后碰巧回滚了正确的项目，那将是纯粹的。

Answer 14

在我工作的地方，让小组主要从DOORS迁移到TFS以满足要求，规范等。他们仍然使用Perforce作为存储库。我已经使用了大部分存储库，每个存储库都有自己的怪癖。

回答你的问题 - 你试图解决的问题是什么？您是否需要集成的解决方案来管理文档，错误和源代码管理？ TFS为您提供了集成部分，以便您每次签入代码时都可以将其标记回错误，要求和规范。如果您的公司使用大量流程，这是一个很棒的功能。对我来说，你的小商店，你真的不需要那种过程。在你变得更大，你的需求发生变化之前，我会坚持自己的工作。