TFS vs SVN [关闭]答案

【问题标题】：TFS vs SVN [closed]TFS vs SVN [关闭]
【发布时间】：2010-10-14 06:24:52
【问题描述】：

我即将开始一个项目 (.NET)，需要在 TFS 和 SVN 之间做出选择。

我比较习惯SVN(with tortoise client)、CVS和VSS。 TFS 是否具备 SVN 中可用的所有功能

你们有没有人从 SVN 切换到 TFS 并觉得值得？
如果我们需要使用 TFS，看起来我们可能需要 Visual Studio。

[编辑]
金钱不是考虑因素，因为我们已经拥有 TFS 的许可证。而且我对 TFS vs SVN 的源代码控制功能更感兴趣，当然也欢迎其他功能列表。

【问题讨论】：

最终使用 TFS，对于我们使用 TFS 的所有新项目。我现在是非官方 TFS 管理员！ TFS 工作项也有助于签入代码以及跟踪任务/错误的状态。
对不起，我不得不说。在两种邪恶之间进行选择时，两者都不选。我强烈建议检查 git（或 Mercurial，如果必须的话）。当然，它只是 VCS，但它和 SVN 的区别就像......你能想象到的任何图像。
在我看来，TFS 获胜主要是因为从 TFS 到 IDE 的任务集成以及您在 TFS Web 应用程序中通过 Sprints 获得的看板系统。我需要一个要处理的任务，我可以转到 TFS Web 应用程序到我们所处的 Sprint 周期，从 Proposed 中抓取 Task，然后将其拖到 Active Column。我执行任务，根据该任务检查代码，然后将任务移至已解决。这是首相的梦想。 PM 让我完成任务，当我解决一个任务时，他们会审查它并关闭它或将其推回给我。以我的经验（在工作中都使用过）TFS 比 svn 提高了生产力。

标签： .net svn version-control tfs configuration-management

【解决方案1】：

"TFS 和 SVN 无法比较"

SVN：是源代码版本控制系统
TFS：是成熟的软件开发管理系统，包含版本控制、发布管理、需求跟踪、文档发布和其他东西。

两者都很好地使用可用于 VS2005 的 IDE 集成插件（例如 AnkhSVN，Collabnet 的插件），所以这不是要考虑的重点。

选择标准：
- 如果您的项目没有预算或预算较少，请选择 SVN
- 如果你只是在寻找版本控制系统选择SVN，如果你正在寻找完整的开发管理选择TFS
- 如果您有耐心使用不同的集成工具（CruiseControl.Net、NUnit、NCover、FIT）来实现适当的开发环境，请选择 SVN，或者如果您正在寻找所有开箱即用的实现然后选择 TFS

【讨论】：

@nils ：我绝对不同意“两者都有很好的 IDE 集成”。 TFS 与 VS 的集成非常完美。 SVN 集成是不完整的（很多功能只能从命令行获得），有时还有点错误。 IDE 集成当然是一个重要的考虑因素。
恕我直言，很多时候我的视觉工作室也开始爬行。如果您寻找合适的插件，您会得到一个错误较少的插件。
VS 的 SVN 插件非常好，在我经历过 TFS 的痛苦之后，再也没有。 TFS 可能与 VS 完全集成，但这并不意味着它使实际的版本控制或简单的功能变得更好。
@Brann：VisualSVN 很好，AnkhSVN 也很好
直到最近，当我升级到最新的 2.1.x 版本时，我都遇到了 AnkhSVN 的问题。从那以后我没有任何问题。

【解决方案2】：

在 18 个月前使用过 TFS，我发现它有问题、速度慢、烦人、搜索条件非常有限，而且感觉产品被一群不感兴趣、报酬过低、工作过度的技术人员强行使用Sharepoint 和其他 MS 技术，因为那是营销人员想要的。说真的，它是一只狗，我宁愿使用 SourceSafe！

另一方面，SVN 有点技术含量，IDE 集成很痛苦，有时会感到困惑，但用户群很大，大多数问题都可以通过快速的 SO 问题得到解决。

你考虑过Vault吗？效果很好，而且价格也不贵。

【讨论】：

18 个月前那是一个公平的评论；使用 TFS 2008 SP1，情况得到很大改善，不再缓慢或错误。
自 SP1 以来我从未在 TFS 中遇到过任何错误
18 个月是一个非常的时间。它的当前版本非常稳定并且运行良好。
也许是失败，但这并不能作为发布如此糟糕的软件的借口，我很高兴错了，但这是一个有效的观点。
保险柜绝对是可怕的。这是我用过的最糟糕的源代码控制系统。

【解决方案3】：

如果您使用 2013 版本并使用基于 Git 的存储库，我只会推荐 TFS。我在以前的版本中遇到了太多问题，认为它们是稳定的。

不可能一次将多个文件发送到您的差异工具。当您想在合并之前查看更改并且不可用时，这非常有用。
功能的可用性不一致。某些功能只能在 IDE 中使用，而其他功能只能在 Windows Explorer 中使用，而还有一些功能只能在命令行中使用。
IDE 无法将文件添加到版本控制中，只能通过 Windows 资源管理器集成来实现。
只能从 IDE 中访问工具架集，而不能通过 Windows 资源管理器集成来访问。
缺少一个统一的安装程序。仅仅安装 TFS 是不够的，您还必须安装团队工具和电动工具才能获得基本功能。
货架集功能未合并。建立私有分支可能是一种很酷的方式，基本上可以保证您的代码会过时并停止工作。
如果您需要使用 Visual Studio 以外的编辑器，则必须在编辑文本文件之前手动解锁。
有时 Visual Studio 会忘记解锁它自己正在管理的文件并引发错误。
检入和搁置 UI 以提交的可用文件为基础，这些文件已添加到 TFS，而不是文件系统中实际存在的文件。这使得丢失文件变得非常容易。（这实际上是 Visual Studio 处理项目文件的方式的问题，但这本身就是另一个问题）。
由于前面提到的问题，使用非 Microsoft 工具编辑源代码变得非常困难。
TFS 配置已与您的源一起提交。这意味着如果您更改 TFS 服务器，所有历史记录的配置现在都不正确。您可以使用一个默认配置来覆盖此行为，但这并不明显。
除了基本级别之外，不支持忽略过滤器。
无法处理超过 249 个字符的路径。
已解锁但未编辑的文件显示为已更改，即使它们尚未更改。区分已更改和已解锁将使差异更容易，或者更好的是完全消除整个损坏的解锁系统。
Windows 资源管理器图标覆盖不能清楚地显示文件是否已被编辑。 TFS 中的所有文件都有一个绿色角落，而修改后的文件在图标底部添加了一支铅笔。切换到红色角落进行修改会更容易看到或使用乌龟系统的图标。
较旧版本的 Visual Studio 在集成到较新版本的 TFS 中时存在问题。这意味着我们现在在源代码控制中有一个 IDE 版本依赖项。
在不需要时默认包含用户解决方案文件。当然，我承认这可能是一个偏好问题。
糟糕的缓存可能无法准确反映本地副本和服务器之间的差异。获取最新信息并发现您实际上没有最新信息，这非常令人沮丧。

【讨论】：

这应该是正确的

【解决方案4】：

我在各种项目中使用 SVN 已经 1.5 年了。到目前为止我使用的设置：

AnkhSVN Visual Studio 客户端。自第 2 版以来，它很好地集成为源代码控制提供程序。
Windows 上的 CollabNet Subversion 或 Apache 2.2 服务器，通过 linux 上的 DAV 使用 SSL + SVN。

这些设置都没有任何问题，我强烈推荐使用 SVN，因为它免费且易于使用。还有许多项目管理/错误跟踪包与 SVN 集成（例如 trac）。

【讨论】：

【解决方案5】：

我会选择 SVN。我以前从开发人员的角度使用过 SVN，而我目前使用的是 TFS，让我告诉你 TFS 很痛苦。虽然 TFS 功能齐全并且不仅仅是版本控制，但它的版本控制充其量只是草率。合并是可怕的，我们中的许多人现在转向手动合并或合并工具，因为我们不能依赖 TFS。文件丢失，有时没有下载到本地系统，而且它的行为有些奇怪，让你想用头撞桌子。

话虽如此，如果您想要 TFS 的所有荣耀，愿意解决其痛点，它是设置自动构建和发布的绝佳工具。

【讨论】：

在我看来，+1 在 TFS 2010 中的合并比使用 SVN 差得多，这从一开始是一个相当大的成就^^
now turn to manual merging - 尝试查找 CheckIn Dance 并遵循它。

【解决方案6】：

在你决定之前看看这篇文章：A Comparison of TFS vs Subversion for Open Source Projects

【讨论】：

我不是 Jeffs 在文章中愉快地评论“Codeplex 永远不会支持 Subversion...它在架构上是不可能的”（2 年前制作）。永远不要说永远不要，比如“我们永远不需要超过 640K 的内存”。 ;)

【解决方案7】：

我都用过——但实际上，我已经将我的主要项目从 TFS 切换到了 SVN。我发现离线和匿名访问在我的项目中非常有价值。

总的来说，我认为它们具有可比性。我只会选择你最了解的一个，你是最快乐的维护者。我没有发现其中一个系统的特定功能明显超过另一个系统的功能。

【讨论】：

是的 - 当然可以，而且效果也很好！
尽管如此，我必须说，离线访问的基本模型已经被打破了。在断开连接的模型中，“签出”操作相当可笑，但 TFS 仍然让您这样做。如果您不这样做，它就不会像 SVN 那样识别您的更改。啊！

【解决方案8】：

如果您熟悉 svn，我会坚持使用它。 Tfs 不是免费的，也不简单。它不仅仅是源代码控制。如果您是像我们这样的 .net 商店，并且您正在决定在整个开发周期中使用什么产品，那么它是一个竞争者，但对于简单的源代码控制来说，它就有点过头了。

【讨论】：

【解决方案9】：

嗯，对我来说，选择显然是 TFS：

SVN 与 Visual Studio 的集成至少可以说是不完整的（IDE 中没有很多功能），而且有点错误（AnkhSVN 肯定是），而 TFS 是完美的（这是有道理的...）。我使用 SVN（在一个月内）多次损坏了我的整个工作区，从未使用过 TFS（大约 2 年）

在解决方案资源管理器选项卡上单击几下即可访问几乎所有 TFS 任务。

使用 TFS 进行合并更容易，即使是复杂的合并（例如，SVN will add <<<<<<'s and >>>>>>>>>'s to your .csproj files，因此您需要手动编辑它们才能从 VS 再次打开它们。）

虽然我认为这些原因足以让我更喜欢 TFS 而不是 SVN，但我必须补充一点：

TFS 不仅仅是一个源代码控制工具（想想工作项、项目门户等）

我过去曾在一个中型项目（12 名编码人员、3 名测试人员、3 名业务分析师）中使用它，并且我们能够成功地将所有任务集中在 TFS 中（错误报告、项目文档、构建过程等）

我并不是说使用 SVN 和其他第三方工具做同样的事情是不可能的，但是将所有东西很好地集成到一个产品中绝对是件好事。

为了公平起见，以下是 TFS 的两个明显缺点：

它的价格
安装 TFS 相当痛苦，而安装 SVN 只需几分钟。

在 SqlServer 2008 上安装 TFS 2008 非常复杂，您无法在 PDC 等上安装 TFS。对我来说，这绝对是我使用 Microsoft 产品时遇到的最糟糕的安装体验。

话虽如此，一旦安装，TFS 非常易于使用（尤其是对于不熟悉源代码控制系统的编码人员）

在我目前的项目中，我从 SVN 开始，并迅速切换到 TFS。我很高兴我做到了。

我决定切换的主要原因显然是 SVN 的整体错误行为（我使用VisualSVN 作为服务器，AnkhSVN 作为客户端）。每周至少有一次，我发现自己会花费数小时来处理神秘的 AnkhSVN 错误消息。

迄今为止，我还没有找到一个后悔改用 TFS 的理由。

【讨论】：

svn + visual svn 和 tortoise svn 非常无缝，丝毫没有错误。
我很难相信您是 TFS 的拥护者，因为我在工作中使用它，这是我遇到的最痛苦的事情。它在合并方面做得很糟糕，虽然 SVN 可能会在冲突上添加标记，但这些很容易修复。使用 TFS 时文件丢失！ TFS 很烂……
如果用户对 AnkhSVN 的可用性有疑问，请通过 users@ankhsvn.open.collab.net 告诉我们。如果您查看我们的邮件存档（可在该站点上找到），您会看到大多数真实的用户问题都在几个小时内得到处理；但我们无法帮助不问我们的用户。
TFS 由于其 Check-Out/Check-In 模型，在“简单合并”之外进行合并是一种痛苦。我讨厌“签出”文件。
@Brann，我简直不敢相信你关于 SVN 和合并 .csproj 文件的评论。如果您认为 TFS 会毫不费力地合并这些，那么您在处理大型合并时会大吃一惊。

【解决方案10】：

我想说 TFS 不仅仅是源代码控制。如果你负担得起，我肯定会建议使用它。例如，当您开始使用 Team Builds 或使用 Work Items 之类的东西时，您会发现 TFS 可以真正管理您的整个开发生命周期，提供丰富的环境，其中报告、易用性、流畅的 VS 集成和可靠的源控制全部合二为一。

服务器端确实需要一些铁。我不觉得它很慢，但是它可以通过 VPN 很好地工作并支持离线工作。

一个主要缺点是安装过程（在服务器端）是乏味的、不灵活的，而且在我看来（我来自一个非常重要的应用程序打包和部署领域）是 SQL 如何使用的一个坏例子可以安装服务器、Reporting Services、Sharepoint 和 web 服务。

【讨论】：

【解决方案11】：

TFS 可以从 SVN 导入，但是 SVN 不能从 TFS 导入。因此，如果您没有找到好的理由，请使用 SVN，因为以后更容易改变主意。

SVN 最大的优点之一是我所知道的每个源代码控制系统都可以从中导入，因此选择 SVN 是一个风险非常低的选择。

【讨论】：

【解决方案12】：

根据我的经验，SVN 总体上更快、更轻松。我已将它与 XCOPY 部署脚本一起使用，与 TFS 相比，它使您的工作和部署总体速度要快得多。

【讨论】：

【解决方案13】：

我没有使用 TFS 的经验，但 IDE 集成是您应该考虑的事情。 TFS 显然 very 很好地与 Visual Studio 集成。 AnkhSVN 是 VS 唯一可用的免费插件，即使在新版本中也经常出现问题。不过，我还没有尝试过 VisualSVN。

【讨论】：

TFS 与 VS 集成，但如果您想将它与 VS 以外的任何东西一起使用，它就不太好了。对我来说，这是一个权衡。 SVN 在 VS 之外工作得更好，但还有其他选择。
就个人而言，我喜欢tortoise-svn。 IDE 应该专注于让我编辑代码 - 我可以单独管理我的 repo，谢谢。大多数情况下，无论如何，如果不在命令行运行我的“正确”构建/测试脚本，我就不会进行提交，因此退出 IDE 不是问题。
这里确认一下：我不使用 AnkSVN 进行更复杂的操作（例如，我不知道这些天它是否可以 svn 复制和合并）但总是有 TortoiseSVN 或 svn 命令行客户端帮帮我。它们一起很好地满足了我的需求（.NET 应用程序上的维护编程）。
我停止使用 AnkhSVN，因为它经常出错，包括损坏的工作副本等等。如果有一个 VS svn 插件会很好用，但 TortoiseSVN 已经足够舒服了。
如果您上一次尝试的AnkhSVN是0.X/1.X版本，请先尝试2.0版本再下结论； 2.0 几乎完全重写了旧版本。重命名、重构等解决方案资源管理器操作都得到处理，并且在大多数情况下比所有其他客户端更快

【解决方案14】：

考虑到 TFS 2010 也可以安装在 Windows Vista / 7 客户端操作系统上，并且它支持快速、三键安装。

【讨论】：

【解决方案15】：

优点：

与 Visual Studio 集成。如果您使用的是完整的 Microsoft 技术，那将是一个真正的优势。用于开发的堆栈。
自动化构建（虽然可以通过其他产品实现）做得非常好。持续集成和门控签入构建是很棒的 IMO。

缺点：

Windows 工作流基础。出于某种原因，选择了 Windows Workflow Foundation 作为自定义 TFS 许多方面的方法。总之，你需要一本关于 Windows Workflow 的书来理解它，而我根本没有时间。 IMO 非常令人失望。
项目管理。我猜工作项的概念很简单，但它有很多奇怪之处让我感到困惑。 IMO 太复杂了。来自 Trac + SVN 背景，我更喜欢 Trac。再说一次，只是我的看法。

【讨论】：

我同意工作流程是一个骗局。我发现它完全无法理解，最终将大部分逻辑放在 MSBuild 任务中。将此与需要大约 10 分钟才能理解的 CruiseControl 和 NAnt 进行比较。不是 Workflow 的最佳广告！
与 Visual Studio 的优点集成？？真的？？以 79 美元的价格查看 Visual SVN 附加组件。真正的区别是相同的 base-SVN 也可以同时用于您的非 VS 项目。 TFS 仅使用 VS 锁定。所以，我说这属于缺点。

【解决方案16】：

如果不了解这些工具的功能及其局限性，则意味着您最终得到的工具无法满足您的需求。了解您的要求，并稍微阅读产品手册 - 大量信息可用于确定适用性。

虽然我完全同意 SVN 的支持者，因为它是一个出色的工具（我在大学里用过很多次），但我发现 TFS 在您使用 SP1 时通常在 OOTB 情况下更加合作带有 Studio 2010 的版本。

还有一些不错的小插件可以让 TFS 对于我们这些习惯并通常更喜欢 SVN 类型的解决方案的人来说更容易接受，其中许多都提供了出色的支持：

用于代码审查的 TeamReview 就是一个例子：http://teamreview.codeplex.com/ 多平台使用 TFS 的 MS Pathways：http://www.microsoft.com/pathways/teamprise/FAQ.htm

这个 SO Question 是 TFS 插件的绝佳资源： What Add-Ons / Utilities are available for TFS?

智者的话，如上所述，安装 TFS 可能会很痛苦，因此应谨慎行事。按照下面的路线，我遇到的问题很少：

Studio 2008 -> 补丁 -> Studio 2010 -> 补丁 -> .NET -> SQL Server 2008RD/2012 -> 补丁 -> TFS -> 补丁

【讨论】：