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

【问题标题】：Should we migrate from svn to Team Foundation Server 2010?我们应该从 svn 迁移到 Team Foundation Server 2010 吗？
【发布时间】：2012-05-01 18:21:59
【问题描述】：

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

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

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

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

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

这是我们当前的堆栈； vs2008 pro、Visual SVN、SVN、Jetbrain Teamcity。我的主要问题是我们使用了许多来自不同供应商的工具，它们或多或少地集成在一起。有时更多，大部分时间更少。至少正确设置它需要很多时间。

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

【问题讨论】：

关于 SVN 与 TFS 2010 的信息似乎很少 当然是这样，TFS 是早期测试版。你期待什么？
@Mitch Wheat，请假设任何开发商店都会有相同的期望：源代码控制、持续集成、代码度量。平常的。

标签： svn visual-studio-2010 visualsvn

【解决方案1】：

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

【讨论】：

完全不同意这些观点。也许你的硬件有问题？
这可能是问题的一部分。或者可能服务器没有正确配置，这就是为什么客户端向服务器发送如此大的数据块以合并一些更改。我只是对 TFS 有足够的了解，想避免它。
+1。它从 sourcesafe 带来的“文件在签出之前始终是只读的”模型真的让我很恼火，并且用于签入/合并/等的 UI 的可用性很差

【解决方案2】：

如果您是 Microsoft 商店，那么 TFS 非常适合。

如果 Subversion 能满足你的所有需求，你会修复没有损坏的东西吗？

你必须有改变的理由。

[我在工作中使用 TFS，它运行良好，几乎没有问题。我在家里使用 Subversion，只是因为我需要更少的基础设施]。

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

【讨论】：

使用 TFS 2010，您可以将其安装在笔记本电脑上。我在家里运行 TFS，因为它是一个 20 分钟的安装，我得到了版本控制、工作项和开箱即用的构建
TFS 试图成为一个完整的应用程序生命周期工具、缺陷跟踪、源代码控制三合一。在我目前和过去使用 TFS 的经验中，我发现它不是解决这些问题的最佳解决方案，并且可以连接的其他专门工具的组合更好（不完美）。带有 JIRA 的 SVN、带有 Teamcity 的 SVN 和带有 JIRA 的 Teamcity 使得堆栈更加灵活和功能齐全。
TFS 有其独特之处，但它适用于源代码控制和 ALM。缺陷跟踪不是我最喜欢的部分......

【解决方案3】：

似乎有很多人建议切换到 TFS，我想另辟蹊径。

我从以前的工作中使用 SVN 转到最近工作的 TFS。我会这样总结：

这种集成很有吸引力，没有其他东西可以将这么多部分集成在一起。权衡是这些单独的部分中的每一个都很糟糕。

更多细节：

源代码控制系统，虽然在服务器等技术上非常好，但使用起来很痛苦。文件始终标记为只读，您必须明确签出它们才能编辑它们。这会让你的生活变得糟糕，除非你 100% 的时间都在使用 Visual Studio 集成......如果你正在使用 Visual Studio 集成，请记住它将所有文件的 SCC 状态存储在 CSPROJ 文件中，所以要准备好处理偶尔的混乱和失败，因为您将文件添加到 TFS，但 Visual Studio 尚未意识到这一点（反之亦然）。

错误跟踪系统搜索效果不佳且有限，UI 难以使用。它让我想起了很多旧的访问数据库表单。将此与一个漂亮干净的基于网络的跟踪器进行比较，它是白天和黑夜。

总体而言，大多数 UI 的可用性都非常差。虽然您可以使用 TFS 完成很多事情，但它不会很快，而且您必须点击太多的组合框！

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

【讨论】：

版本控制 - TFS 的工作方式与 SVN 不同。克服它。所有产品在某些方面有所不同。如果您真的无法适应，请让您的管理员从 Codeplex 安装 SVNtoTFS 网桥。
Bug Tracking - 您是否意识到 TFS 中集成了 Excel 和 Project？您还可以获得一个非常好的带有搜索功能的 Web 界面。 +您可以在团队资源管理器中创建您喜欢的任何个人查询。我从未见过有更多搜索选项的产品......好吧，除了全文，但有些东西你必须忍受
我不反对 TFS 以不同于 SVN 的方式工作。我的观点是，您在使用 TFS 时会遇到许多问题和痛点（我列出了）。如果使用起来很痛苦是因为它的工作方式不同，或者只是因为它有问题，那么这是一个单独的问题。
关于全文搜索，如果没有它你也能活下去，那你可能会很开心。但有时，没有它你就活不下去。

【解决方案4】：

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

TFS 可以进行源代码控制、错误/问题跟踪、自动构建、为经理报告，并且可以治愈男性型秃发。它的默认客户端是 Visual Studio。

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

如果您想要自动构建、持续集成、签入政策和规则、报告、问题跟踪，并且您希望这一切合二为一，那么 TFS 适合您 - 假设您不会冒险使用 Microsoft 开发工具（通常 - 那里是其他 IDE 的插件）。您可以使用其他 FOSS 工具获得相同的东西，并用胶带将它们包裹在 SVN 周围，这也有效，只是不够无缝，需要更多投资。

但是，您将源代码控制系统与开发生命周期管理工具进行比较。 TFS 进行源代码控制，但它的功能远不止这些。

【讨论】：

@blowdart 提出了一些非常有说服力的论点 :) 如果您真的想使用 SVN 功能，那么您可以使用 codeplex 的 SVN To TFS 适配器。他们在服务器上使用它。

【解决方案5】：

确实，您应该尝试使用新的测试系统来评估它。很多人讨厌 TFS，有些人认为它不适合他们的工作方式。此外，当您必须开始购买更好版本的 VS 以获得您上瘾后想要的附加功能时，它也不是那么免费。

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

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

【讨论】：

【解决方案6】：

我在必要时使用了 TFS，并且讨厌它的每一分钟。它只是挡住了我太多的路，远程做任何事情都需要很长时间。但主要是我的非理性仇恨。如果您的六个程序员中有一个像我一样，那么您将遇到问题。而且程序员比工具更重要。

【讨论】：

程序员来了，程序员走了，但你的工具集仍然存在。我认为你有一种非理性的仇恨，也许是次规格的硬件。我从英国连接到悉尼的 TFS 服务器，没有任何问题...
工具集仍然存在，但工具集实际上并没有做任何工作。您不会通过安装任何工具来获得报酬，而是通过出售程序员制作的工作来获得报酬......如果您的工具集使您的程序员难以工作，或者导致程序员避开您的公司，那么也许需要更换工具集：-P

【解决方案7】：

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

【讨论】：

你说支持，但如果我遇到的问题是一个错误，甚至只是设置不佳，他们会来解决它吗？微软会！好吧，取决于您的支持协议；）
我在中东，虽然在迪拜有MS分店，但是他们不会来的！在这里，如果互联网让你失望，那么你就完蛋了。

【解决方案8】：

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

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

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

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

【讨论】：

您知道 TFS 现在对所有 MSDN 订阅者都是免费的！如果您有任何非 MSDN 用户，您可以以低于 500 美元的价格为您的零售 TFS 支付 5 个用户...

【解决方案9】：

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

也... TFS“似乎”/“似乎”在一些非常基本的事情上挣扎，例如如何忽略您不想放入存储库的文件，它经常将文件标记为已更改，差异显示为相同。

【讨论】：

【解决方案10】：

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

【讨论】：

该链接来自 2006 年；从那以后，情况发生了变化，尽管不是根本性的。

【解决方案11】：

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

在我看来，你不应该迁移并保持简单。只有 6 名开发人员，您将无法完成任何复杂到使用 TFS2010 高级功能的一部分。

VisualSVN 是一个很好的工具，可以让您充分“集成”。并且会更加完善。

【讨论】：

【解决方案12】：

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

我有没有提到它在 VS 2010 中是免费的

【讨论】：

【解决方案13】：

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

尽管 TFS 为您提供了与 Visual Studio 的 Source Safe 风格集成，但细节到此为止。 SVN 在版本控制方面要好得多，Mingle 是更好的协作工具，而 MediaWiki 是更好的 wiki。

如果您需要测试 TFS 的主要产品作为源代码控制，则创建多个 TFS 项目，添加一些更改并尝试恢复到以前的版本。您需要一个命令提示符工具，如果您在按照伪劣的在线说明操作后碰巧回滚了正确的项目，它会很简单。

【讨论】：

【解决方案14】：

在我工作的地方，让团队从 DOORS 迁移到 TFS，主要是为了满足需求、规范等。他们仍然使用 Perforce 作为存储库。我已经使用了那里的大多数存储库，每个存储库都有自己的怪癖。

回答您的问题 - 您要解决的问题是什么？您是否需要一个集成的解决方案来管理您的文档、错误和源代码控制？ TFS 为您提供了集成部分，因此每次您签入代码时，您都可以将其标记回错误、需求、规范。如果您的公司使用大量流程，这是一个很棒的功能。在我看来，你是一家小商店，你真的不需要那种过程。我会坚持使用有效的方法，直到您变得更大并且您的需求发生变化。

【讨论】：