我即将开始一个项目（.NET），需要在 TFS 和 SVN 之间做出决定。
我更习惯于 SVN（带乌龟客户端）、CVS 和 VSS。TFS 是否具有 SVN 中可用的所有功能
你们中有人从 SVN 切换到 TFS 并发现它值得吗？
如果我们需要使用 TFS，看起来我们可能需要 Visual Studio。
[编辑]
金钱不是考虑因素，因为我们已经拥有 TFS 的许可证。而且我对 TFS vs SVN 的源代码控制功能更感兴趣，当然也欢迎其他功能列表。
Binoj Antony
问问题
40638 次
16 回答
84
“ TFS 和 SVN 无法比较”
SVN : 源代码版本控制系统
TFS : 成熟的软件开发管理系统，包含版本控制、发布管理、需求跟踪、文档发布等。
两者都很好地使用了可用于 VS2005 的 IDE 集成插件（例如 AnkhSVN，Collabnet 的插件），所以这不是要考虑的重点。
选择标准：
- 如果您有无预算或小预算项目，请选择SVN
- 如果您只寻找版本控制系统，请选择SVN，如果您正在寻找完整的开发管理，请选择TFS
- 如果您有耐心处理不同的问题集成工具（CruiseControl.Net、NUnit、NCover、FIT）以实现适当的开发环境选择SVN，或者如果您正在寻找所有这些开箱即用的实现，请选择TFS
于 2009-03-19T08:48:04.640 回答
32
18 个月前使用过 TFS，我发现它有问题、缓慢、烦人、非常有限的搜索条件，并且感觉产品被一群不感兴趣、报酬过低、工作过度的技术人员被迫使用 Sharepoint 和其他MS 技术，因为那是营销人员想要的。说真的，它是一只狗，我宁愿使用 SourceSafe！
另一方面，SVN 有点技术含量，IDE 集成很痛苦，有时会感到困惑，但用户群很大，大多数问题都可以通过快速的 SO 问题得到解决。
你考虑过保险柜吗？效果很好，价格也不贵。
于 2009-03-19T08:06:04.210 回答
24
如果您使用 2013 版本并使用基于 Git 的存储库，我只会推荐 TFS。我在以前的版本中遇到了太多问题，认为它们是稳定的。
- 一次将多个文件发送到您的差异工具是不可能的。当您想在合并之前查看更改并且不可用时，这非常有用。
- 功能的可用性不一致。某些功能只能在 IDE 中使用，而其他功能只能从 Windows 资源管理器中使用，而还有一些功能只能在命令行中使用。
- IDE 无法将文件添加到版本控制，只能通过 Windows 资源管理器集成进行。
- 只能在 IDE 中访问货架集，而不能通过 Windows 资源管理器集成访问。
- 缺乏一个统一的安装程序。仅安装 TFS 是不够的，您还必须安装团队工具和电动工具才能获得基本功能。
- 货架集功能不合并。建立私有分支可能是一种很酷的方式，基本上可以保证您的代码会过时并停止工作。
- 如果需要使用 Visual Studio 以外的编辑器，则必须在编辑文本文件之前手动解锁它们。
- 有时 Visual Studio 会忘记解锁它自己正在管理的文件并引发错误。
- 签入和搁置 UI 基于已添加到 TFS 的可用文件提交，而不是文件系统中实际存在的文件。这使得丢失文件变得非常容易。（这实际上是 Visual Studio 处理项目文件的方式的问题，但这本身就是另一个抱怨）。
- 由于前面提到的问题，使用非 Microsoft 工具编辑您的源是不必要的困难。
- TFS 配置与您的源一起提交。这意味着如果您更改 TFS 服务器，所有历史记录的配置现在都不正确。您可以使用一个默认配置来覆盖此行为，但这并不明显。
- 除了基本级别，不支持忽略过滤器。
- 无法处理超过 249 个字符的路径。
- 已解锁但未编辑的文件显示为已更改，即使它们尚未更改。区分更改和解锁将使差异更容易，或者更好的是完全消除整个损坏的解锁系统。
- Windows 资源管理器图标覆盖不能清楚地显示文件是否已被编辑。TFS 中的所有文件都有一个绿色角落，而修改后的文件在图标底部添加了一支铅笔。切换到红色角落进行修改会更容易看到或使用乌龟系统的图标。
- 旧版本的 Visual Studio 在新版本的 TFS 中集成时存在问题。这意味着我们现在在源代码控制中有一个 IDE 版本依赖项。
- 默认情况下包括不需要的用户解决方案文件。当然，我承认这可能是一个偏好问题。
- 糟糕的缓存可能无法准确反映本地副本和服务器之间的差异。获取最新信息并发现您实际上没有最新信息是非常令人沮丧的。
于 2012-05-10T01:42:45.400 回答
14
我在各种项目中使用 SVN 已经 1.5 年了。到目前为止我使用的设置：
- Visual Studio 的AnkhSVN客户端。自版本 2 以来，它很好地集成为源代码控制提供程序。
- 服务器要么是Windows 上的CollabNet Subversion ，要么是带有 SSL + SVN 的 Apache 2.2 通过 Linux 上的 DAV。
这些设置都没有任何问题，我强烈推荐使用 SVN，因为它免费且易于使用。还有许多项目管理/错误跟踪包与 SVN 集成（例如trac）。
于 2009-03-19T09:33:25.950 回答
12
我会选择SVN。我以前从开发人员的角度使用过 SVN，而我目前使用的是 TFS，让我告诉你 TFS 很痛苦。虽然 TFS 功能齐全并且不仅仅是版本控制，但它的版本控制充其量只是草率。合并是可怕的，我们中的许多人现在转向手动合并或合并工具，因为我们不能依赖 TFS。文件丢失，有时没有下载到本地系统，而且它的行为有些奇怪，让你想把头撞在桌子上。
话虽如此，如果您想要 TFS 的所有荣耀，愿意解决其痛点，它是设置自动构建和发布的绝佳工具。
于 2009-03-19T15:17:00.217 回答
10
在你决定之前看看这篇文章：开源项目的 TFS 与 Subversion 的比较
于 2009-03-19T08:00:59.307 回答
9
我都使用过——但实际上，我已经将我的主要项目从 TFS 切换到了 SVN。我发现离线和匿名访问在我的项目中非常有价值。
总的来说，我认为它们具有可比性。我只会选择你最了解的一个，你是最快乐的维护者。我没有发现一个系统中的特定功能明显超过另一个系统中的功能。
于 2009-03-19T08:04:52.107 回答
7
如果您熟悉 svn，我会坚持使用它。Tfs 不是免费的，也不简单。它不仅仅是源代码控制。如果您是像我们这样的 .net 商店，并且您正在决定在整个开发周期中使用什么产品，那么它是一个竞争者，但对于简单的源代码控制来说，它是矫枉过正的。
于 2009-03-19T09:56:28.127 回答
4
好吧，对我来说，选择显然是 TFS ：
SVN 与 Visual Studio 的集成至少可以说是不完整的（IDE 中没有很多功能），而且有一点问题（AnkhSVN 肯定是），而 TFS 是完美的（这是有道理的......）。我使用 SVN（在一个月内）多次损坏了我的整个工作区，从未使用过 TFS（大约 2 年）
虽然这两个系统的源代码控制相关功能可能相当相似，但它们可以直接从带有 TFS 的 IDE 访问，而如果您使用 SVN，则必须依赖TortoiseSVN或其他外部工具。在解决方案资源管理器选项卡上单击几下即可访问几乎所有 TFS 任务。
使用 TFS 进行合并要容易得多，即使是复杂的合并（例如，SVN 会将 <<<<<<'s 和 >>>>>>>>>'s 添加到您的 .csproj 文件中，因此您需要手动编辑它们以从 VS 再次打开它们。）
虽然我认为这些原因足以让我更喜欢 TFS 而不是 SVN，但我必须补充一点：
TFS 不仅仅是一个源代码控制工具（想想工作项、项目门户等）
我过去曾在一个中型项目（12 名编码员、3 名测试员、3 名业务分析师）中使用它，并且我们已经能够成功地将所有任务集中在 TFS 中（错误报告、项目文档、构建过程、 ETC。）
我并不是说使用 SVN 和其他第三方工具做同样的事情是不可能的，但是将所有东西很好地集成到一个产品中绝对是件好事。
为了公平起见，以下是 TFS 的两个明显缺点：
它的价格
安装 TFS 相当痛苦，而安装 SVN 只需几分钟。
在 SqlServer 2008 上安装 TFS 2008 非常复杂，您无法在 PDC 等上安装 TFS。对我来说，这绝对是我使用 Microsoft 产品时遇到的最糟糕的安装体验。
话虽如此，一旦安装，TFS 就非常易于使用（尤其是对于不熟悉源代码控制系统的编码人员）
在我目前的项目中，我从 SVN 开始，并迅速切换到 TFS。我很高兴我做到了。
我决定切换的主要原因显然是 SVN 的整体错误行为（我使用VisualSVN作为服务器，AnkhSVN作为客户端）。至少每周一次，我发现自己花费数小时处理神秘的 AnkhSVN 错误消息。
迄今为止，我还没有找到一个后悔改用 TFS 的理由。
于 2009-03-19T08:23:51.703 回答
3
我想说 TFS 不仅仅是源代码控制。如果你负担得起，我肯定会建议使用它。例如，当您开始使用 Team Builds 或使用 Work Items 之类的东西时，您会发现 TFS 可以真正管理您的整个开发生命周期，提供丰富的环境，其中报告、易用性、流畅的 VS 集成和可靠的源控制全部合二为一。
它确实需要服务器端的一些铁。但是我不觉得它很慢，它在 VPN 上运行良好，并且支持离线工作。
一个主要缺点是安装过程（在服务器端），它是乏味的、不灵活的，在我看来（我来自打包应用程序和部署非常重要的领域）是 SQL Server、报告的一个坏例子可以安装服务、Sharepoint 和 web 服务。
于 2009-03-19T09:48:45.757 回答
2
TFS 可以从 SVN 导入，但是 SVN 不能从 TFS 导入。因此，如果您没有找到好的理由，请使用 SVN，因为以后更容易改变主意。
SVN 最好的一点是我所知道的每个源代码控制系统都可以从中导入，因此选择 SVN 是一个风险非常低的选择。
于 2009-03-19T16:43:13.567 回答
2
以我的经验，SVN 总体上更快、更轻松。我已经将它与 XCOPY 部署脚本一起使用，与 TFS 相比，这些脚本使您可以更快地工作和部署。
于 2013-08-22T04:09:10.903 回答
1
我没有使用 TFS 的经验，但 IDE 集成是您应该考虑的事情。TFS 显然与 Visual Studio集成得非常好。AnkhSVN 是 VS 唯一可用的免费插件，即使在新版本中也经常出现问题。不过，我还没有尝试过 VisualSVN。
于 2009-03-19T08:02:09.180 回答
1
考虑到 TFS 2010 也可以安装在 Windows Vista / 7 客户端操作系统上，并且它支持快速、三单击安装。
于 2010-02-12T10:11:19.730 回答
1
优点：
- 与 Visual Studio 集成。如果您使用的是完整的 Microsoft 技术，那将是一个真正的优势。堆栈进行开发。
- 自动化构建（尽管可以通过其他产品实现）确实做得很好。持续集成和门控签入构建是很棒的 IMO。
缺点：
- Windows 工作流基础。出于某种原因，选择了 Windows Workflow Foundation 作为自定义 TFS 的许多方面的方法。总之，你需要一本关于Windows Workflow的书来理解它，而我根本没有时间。非常令人失望的国际海事组织。
- 项目管理。我猜工作项的概念很简单，但它有很多奇怪的地方让我感到困惑。IMO 太复杂了。来自 Trac + SVN 背景，我更喜欢 Trac。再说一次，只是我的看法。
于 2011-09-14T13:36:49.610 回答
0
不了解这些工具的功能及其局限性，将意味着您最终得到的工具无法满足您的需求。了解您的要求，并稍微阅读产品手册 - 大量信息可用于确定适用性。
虽然我完全同意 SVN 的支持者，因为它是一个出色的工具（我在大学里用过很多次），但我发现当您使用带有 Studio 的 SP1 版本时，TFS 通常在 OOTB 情况下更加合作2010 年。
此外，还有一些不错的小插件可以让 TFS 对我们这些习惯并且通常也更喜欢 SVN 类型解决方案的人来说更可口，其中许多都提供了出色的支持：
用于代码审查的 TeamReview 就是一个示例：http ://teamreview.codeplex.com/ 用于 TFS 的多平台使用的 MS 路径：http: //www.microsoft.com/pathways/teamprise/FAQ.htm
这个 SO 问题是 TFS 插件的一个很好的资源： 哪些插件/实用程序可用于 TFS？
智者的话，如上所述，安装 TFS 可能会很痛苦，因此应谨慎行事。按照下面的路线，我遇到了最小的问题：
Studio 2008 -> 修补 -> Studio 2010 -> 修补 -> .NET -> SQL Server 2008RD/2012 -> 修补 -> TFS -> 修补
于 2012-01-10T19:45:57.700 回答