SVN 对比Team Foundation Server [关闭]
https://stackoverflow.com/questions/4219
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian解决方案
我最近加入了 CodePlex 的一个开源项目。他们使用 TFS 进行源代码控制，我不得不说这绝对是非常棒的。到目前为止，我对它印象深刻。我非常喜欢 IDE 集成以及分支和标记代码是多么容易。如果您已经正确配置了所有内容，则将解决方案添加到源代码管理只需单击两次即可。
现在。是否值得高昂的价格标签？我不这么认为。在 CodePlex 从事项目的好处是，它可以让我获得所需的 TFS 经验，以防我以后必须在某个地方使用它。如果您想为源代码管理提供良好的 IDE 集成，请获取 视觉SVN 集成包。获得许多相同的功能是一项非常非常便宜的投资（顺便说一句，在非域计算机上免费）。
其他提示
以下是对我来说两者之间最大的区别，我都使用过：
1) TFS 与进行开发的“Visual Studio 方式”紧密耦合。 这并不是说 TFS 与 VS IDE 紧密耦合，而是意味着 TFS 很难保持熟悉的 Visual SourceSafe“签入”/“签出”范例，即使它确实不再是合适的模型。当您的开发人员可能会花时间与网络断开连接时，Subversion 的“提交”/“更新”概念更加现实。TFS 希望开发人员始终连接到服务器。这是一个很大的减分。我个人认为，由于与 Visual Studio 的紧密集成，TFS 对于文件在服务器和本地磁盘上的组织方式不太透明。即使是 TFS 的大力支持者也承认，对于离线工作的开发人员来说，其联网签入/签出模型并不是一个有吸引力的选择。在人们开始关注 DVCS 选项（如 git 和 Mercurial）而不是 SVN 的环境下，TFS 的“签出”模型似乎有点像恐龙。
2) 成本。 那些说TFS不贵的人要么是非常小的商店，要么不遵守TFS的许可条款。您所做的几乎所有事情都需要客户端访问许可证。您是一名只负责管理 bug 的经理吗？您需要大约 250 美元的 CAL（零售 TFS 许可证包含 5 个）。只想报告问题的企业用户？250 美元。开发商？250 美元（除非他们有 MSDN，在这种情况下它包含在内）。服务器？500 美元（如果您有 MSDN，则包含在内）。当然，向您出售 TFS 副本的人会告诉您，工作项跟踪对于其他用户是免费的，但这些额外用户只能看到他们自己创建的工作项，而看不到整个团队的工作项，这不是在面向团队的敏捷环境中太有用了。当您拥有一个中型组织时，所有这些都会增加，并且当 SVN 和 CruiseControl.net 等众多同类最佳产品的增量成本为 0 美元时，所有这些都变得难以证明其合理性。（不过，公平地说，我仍在等待 TFS 真的 良好的 OSS 问题跟踪器）
3) 项目结构。 在项目数量较少的大型团队中，TFS 可能会运作良好。如果您内部有许多小型、未连接或松散连接的业务线应用程序，那么 TFS 的结构可能会开始变得霸道。一方面，不可能定义项目本身的分类法——您可以在项目内设置“区域”，但所有问题和文档都在“项目”的基本上下文中一起跟踪。创建新的“项目”通常非常耗时，而且对于小努力来说是多余的。当然，SVN 没有这样的功能，因为它只专注于源代码控制，但如果您需要良好的小项目灵活性，SVN 和其他问题跟踪工具可能是更好的选择。
我的意见是，就其价值而言：
对于拥有大型且预算充足的项目的大型团队来说，在 Microsoft 商店中，开发人员几乎完全在 IDE 中工作，TFS 是赢家。当您需要对项目集中执行策略时，TFS 也会胜出。
对于许多小型团队来说，他们有许多不同的小型项目，或者成本是一个问题的商店，或者开发人员与源代码控制脱节的团队，可以选择 SVN。
我很惊讶以前使用过 Subversion 的人甚至会想要/需要 TFS 源代码控制。
我对 TFS (2005) 的体验非常糟糕。我读过各种白皮书和指南，了解如何正确构建源代码以满足各种开发需求。
我们的简单情况是，我们有一个主线开发的主干，一个集成分支，我们在其中集成更改和部署，以及一个发布分支来跟踪过去的版本，这是非常常见和简单的，但我们不断遇到问题。
我对 TFS 的主要问题：
- 与颠覆相比，合并是一种痛苦。
- 有未修复的错误。我遇到了一个关于重命名/合并的问题，这个问题已经存在 2 年了，并且 2005 年永远不会发布修复程序。我们最终将分支移至“损坏的”文件夹，现在忽略它。
- 对文件设置只读锁会产生摩擦。谁说我需要在 TFS 中编辑批处理文件并构建脚本，以便它能为我“检查”？颠覆 知道 哪些文件发生了变化。那里没有只读锁。
- 速度。TFS 在 WAN 上速度慢得要命，而且只有当我通过 VPN 连接到我的工作计算机时它才可用，这使得我的开发体验整体上非常慢。
- 缺乏良好的命令行和资源管理器集成。IDE 集成对于日常获取最新、添加文件和签入确实非常有用，但是当您需要在多个项目中执行操作时，最好有可用的好工具。在有人对我说 tf.exe 运行良好之前......它并不是真正的命令行工具。例如，签入代码不应弹出模式对话框。
...这样的例子还在继续。我认为即使有了所有的集成，仍然有更好的免费替代品。
正如其他人指出的那样，TFS 为您提供了比 SVN 更多的功能，例如项目管理等。我使用过这两种方法，并与非常大的公司合作实施 TFS，这是我的两点看法。
1) 如果您使用的是 TFS 2005，请升级到 TFS 2008。你会感谢我的。TFS 2008 中有大量改进使其变得可行。
2) 如果您使用 Visual Studio 并且想要 IDE 集成，请使用 TFS。我使用过 SVN 集成，但几乎总是转而使用 TortoiseSVN。
3) 如果您喜欢将帐户与 Windows 身份验证集成的想法，请选择 TFS。这方面的可管理性很好。SVN 可能有其吸引力——我对此并不肯定，但如果您喜欢 GUI 驱动的管理，那么 TFS 很难被击败。
4) 如果您需要跟踪指标或有更简单的方法来实施签入策略等内容，请使用 TFS。
5) 如果有人不愿意实施非 MSFT，请选择 TFS。
6) 如果您不仅仅做 .NET（Java 工作、Eclipse 等），请使用 SVN。是的，有非常好的产品（例如 Teamprise）可以与 TFS 配合良好。但除非其他语言只占你商店的一小部分，否则就坚持使用 SVN。
除此之外，两者的 SCM 功能大致相同。它们都进行分支和合并，都进行原子签入，都支持重命名和移动。我认为对于刚刚开始使用分支和合并概念的人来说，让分支在源代码管理资源管理器中可见是很好的。
TFS 确实没那么贵（也许 1200 美元？）。与 SVN 相比，也许是这样。报告服务和 SharePoint 的集成很好，但同样，如果您不使用它，那么也没关系。
我想说的是下载 TFS 180 天试用版并尝试一下。并行进行试验。我想，无论你走哪条路，你都会幸福。
正如 Ubiguchi 指出的那样，TFS 不是版本控制产品。购买 TFS 的目的只是为了版本控制，这显然是浪费钱。TFS 是一套集成的工具，用于自动化应用程序生命周期管理的各个方面（并且非常适合“企业”）。
另外，根据 Ben S 的帖子 - 我不明白你对锁的评论。TFS 中根本不需要锁。管理员可以将 TFS 配置为像 VSS（一些“不明智”的客户所要求的功能）一样“在结帐时获取最新信息”，我相信这也可以实现结帐锁定。
但通过“正常”使用 TFS，“签出”会提示用户输入锁定类型 - 默认值应为“无”。用户可以选择签出（或签入锁）——但这不是必需的。如果您不需要锁，请不要使用它们。
TFS 确实会出于各种性能原因（使获取最新速度更快）和项目管理（我喜欢查看开发人员签出哪些文件以及他们的签出时间）来跟踪哪些用户在服务器上签出。
我对 SVN 不太熟悉（我从未使用过它） - 所以我不能评论“TFS 合并更糟糕” - 并且还没有遇到 Ben S 报告的合并错误 - 但我玩得很开心使用 TFS 成功进行分支和合并。
我知道 TFS 的一个用例仍然相当薄弱，那就是对于经常“离线”的用户。TFS 是一种“服务器产品”，假设用户大部分时间都处于连接状态。离线体验在 2008 年版本中有所改善（2005 年很惨淡），但仍有很长的路要走。如果您的开发人员需要（或想要）经常长时间与网络断开连接，那么使用 SVN 可能会更好。
使用 TFS 的 SVN 粉丝需要考虑的另一个功能是 SVN桥 允许用户使用 TortiseSVN 连接到 TFS 的 codeplex。我的好朋友和同事广泛使用它并且喜欢它。
另外，关于缺乏命令行的评论也让我感到惊讶 - 命令行工具非常广泛（尽管许多需要单独下载 TFS 电动工具
我怀疑 Ben 的评论是基于对 2005 年版本的评估，该版本显然是“Microsoft V1.0”产品。该产品目前为 2.1 版本，不久的将来将推出版本 3。
TFS是令人发指的。此时，我使用 SVN（带有用于备份的 Live Mesh）进行本地版本控制，因为我在 TFS 方面遇到了很多问题。主要问题是TFS使用时间戳来记录您是否拥有最新版本，并将这些时间戳存储在服务器上。您可以删除本地副本，从 TFS 获取最新版本，它会说所有文件都是最新的。这是一个愚蠢的系统，无法保证您拥有正确版本的文件。这会导致许多烦恼：
- 编辑任何文件时都需要通知 TFS，因此您需要始终连接到服务器。
- 如果您在 IDE 之外编辑文件，TFS 会感到困惑。此外，它将 NTFS 中的所有文件设置为只读。
虽然 TFS 支持合并，但它实际上是一个签入/签出系统。如果您编辑文件，您经常会发现它被其他开发人员锁定。有很多方法可以解决这个问题，但系统非常复杂，你总会遇到这个问题。例如，我们的开发人员发现，他们可以通过检查整个解决方案（该解决方案对所有文件设置独占锁）来绕过 NTFS 中所有文件被设置为只读的问题。我这样做了几次，因为 subversion 具有相同的 checkout 语法，它不会获取锁。
最后，Team Explorer（客户端）高达 400 MB，TFS 服务器需要 SharePoint 和两天的时间来安装。Subversion 一键安装程序大约为 30 MB，它将在一分钟内为您安装服务器。TFS 有很多功能，但它的基础很不稳固，你永远不会使用或关心它们。TFS 就许可证而言是昂贵的，开发人员会浪费时间在 stackoverflow 上咆哮而不是编写代码:P
我的建议是，团队系统不值这个钱。我都用过，在使用 Team System 后，我试图找到类似的替代品。基本上，您支付的是集成费用，您可能会争论定制支持，但我已经能够用一点时间创建一个团队系统替代品并将工具集成在一起。
我最近 问了一个问题 关于其他人为提出团队系统替代方案所做的工作。我还列出了用于创建替代品的开发工具。希望通过这个答案和我提出的问题，您可以找到适合您的方法。
我并不是讨厌团队系统，我只是认为它不值这个钱。这是一个非常好的工具，如果您不介意为此付出代价，那么请务必使用它。这就是我创建我想出的替代品的全部原因。我想要团队系统提供的功能。
这是 VisualSVN 的开源版本，名为 安赫森。现在 collabnet 已经接管了它，情况好多了。
如果您需要的只是源代码控制，那么 TFS 就有点过分了。我以前的一位雇主在他们的企业中拥有 TFS、VSS 和 Subversion。我们的企业中没有 Active Directory 或 Exchange Server 2003，因此我们最终在 TFS 服务器上创建单独的用户，以便开发人员可以使用它。我们在合并方面遇到了 Ben Schierman 提到的同样的问题，以及其他促使我们转向 Subversion 的错误行为。
TFS 是否适合您将部分取决于您的预算、开发团队的规模以及可用于配置/维护解决方案的时间和人员数量。如果您需要 TFS 提供的附加问题跟踪、工作项和项目统计功能，那么可能值得您花时间考虑其他替代方案。JIRA（来自 Atlassian Systems）或 Trac 等产品与 Subversion 很好地集成，并以较低的价格为项目或项目经理提供了某种监督。
在理想的环境中，如果有 Active Directory、Exchange Server 2003 或更高版本以及专门的存储库人员，TFS 更有可能是一个不错的选择。
TFS 不仅仅是源代码控制。如果您使用 TFS 提供的整个包、错误跟踪、构建、报告等，那么 TFS 是一个相当可靠的选择（当然比 Rational 更好）。TFS 还与 Active Directory 很好地集成。
不过如果你只是谈论 SCM，那么我更喜欢 SubVersion。我不太喜欢 IDE 集成。我也喜欢 SVN 的主干/标签/分支结构约定，以及在分支之间相对轻松的切换。不过，在 TFS 中合并似乎更容易。不过，Tortoise 的 UI 轻而易举地击败了 TFS，尤其是在将文件添加到存储库方面。
我想说这真的取决于你的需求。TFS 非常好，我广泛使用过它，但它主要针对企业级，如果您不需要所有这些功能，则可能没有必要。如果您确实需要这些功能（特别是分支、可扩展性、工作项跟踪等），那么它们是值得的。请记住，TFS 包括错误跟踪、工作项跟踪和源代码控制之外的其他功能。如果您有多个分支，或者您发现自己在 Subversion 中遇到某些功能缺失或其他问题，那么切换可能是个好主意。但是，除非有充分的理由进行切换，否则您应该避免切换源代码控制系统对成本和生产力的影响。
在广泛使用这两者后，我认为 Wedge 注意到“TFS 包括错误跟踪、工作项跟踪和源代码控制之外的其他功能”，这是很有价值的。
然而，我可以诚实地说，SVN 和 TFS 在可扩展性方面似乎相当相同，而且如果有什么不同的话，那就是 SVN 的源代码控制由于其固有的简单性而优于 TFS。
如果您希望在源代码控制的同时进行工作项和错误跟踪，那么您要么使用 TFS，要么使用 SVN 和其他一些可能免费的工具，例如 bugzilla。虽然 TFS 确实将源代码控制和工作项跟踪集成在一起，但我真诚地认为 MS 应该免费赠送它，作为多年来滥用 VSS 的众多开发人员的道歉。
我用过SVN和TFS。使用 TFS 的主要优点是它与 Visual Studio 的紧密集成。错误跟踪、任务跟踪都将集中在一处。为这些项目生成的报告将帮助利益相关者了解项目状态。
我正在与 5 个人一起开发一个项目，我们最近从 SVN 切换到 TFS。整个过程简直就是一场噩梦。我们有从 XMLSpy 自动生成的代码，并且 TFS 无法识别在 VS2008 之外修改的文件。TFS Power Tools 可以扫描您的结帐并解决此问题，但必须记住使用这些工具是一件痛苦的事情。我们经常遇到的另一个问题是 TFS 中的默认合并工具。这是迄今为止我用过的最糟糕的合并工具。人们可能会认为 TFS 能够处理基本的解决方案合并，但到目前为止情况并非如此。
内置的用户界面非常有用，但也有缺陷。如果我从解决方案资源管理器中签出，有时已添加的文件不会签出。如果我从“团队源代码控制”窗口执行此操作，它会完美运行。这是为什么？我期待 VS2010 中的 TFS，因为我听说过有关它的伟大的事情，并且 SVN 远非完美，但我希望其中一些功能能够更直观地发挥作用。
亚当
TFS 非常适合项目管理和跟踪，但我觉得源代码控制不如 SVN。以下是我对 TFS 的不满：
入住/退房模式
这对于 TFS 源代码控制来说是一个巨大的弊端。不幸的是，即使您不想，VS 也会自动为您检查项目。我曾经遇到过这样的情况：有人检查了一些文件，然后就去度假了。我负责重组目录结构，但无法做到，因为一堆文件已签出给该人。GUI 中无法撤消结帐，这意味着必须在命令行中一项一项地完成。或者我必须弄清楚如何为此编写一个 power shell 脚本。
一切都需要VS来做
有时我想编辑一个文本文件并将其签入。这需要我启动 VS 2010，它是一个巨大的野兽，只是为了编辑文件并将其签入。以前用 SVN 需要几秒钟的事情现在只需要我一分钟。
正如其他一些人指出的那样，如果文件未检出，则它们会被标记为只读。如果您将其设置为可写并在 VS 之外对其进行编辑，TFS 将无法识别这一点。这使得在 VS 之外编辑一些东西变得很烦人。这意味着，启动 VS，检出文件，在另一个编辑器中编辑它，然后在 VS 中检入。
一些在 SVN 中很容易的操作现在变得很痛苦
也许我还没有弄清楚，但我发现使用 TFS 回滚变更集非常乏味。
将文件添加到源代码管理中（这不是解决方案的一部分）是一个巨大的痛苦。TFS 源代码管理资源管理器仅显示哪些文件在源代码管理中，而不显示哪些文件不在源代码管理中（也许在某处有一个设置，我不知道）。使用 Tortoise SVN，我只需在文件夹上按“提交”并选择要添加的文件即可。
目前，我正在领导根据我们目前使用的 Rational Suite 来评估我公司的 TFS。到目前为止，TFS 2008 正在破解 Clearcase + ClearQuest。开发环境集成是它真正的亮点。
我的10美分：
TFS2005是个笑话 - 很难安装，甚至更难维护TFS2008是稳定的 - 更易于安装程序，更简单的维护和可行的自动化构建。TFS2010 是史诗般的！- 安装是dog eassssyyy。管理非常简单；这是一个布局精美的用户界面。将它与 VS2008 集成并不是那么容易，因为你无法在 vs2008 中创建项目，你必须使用 vs2010（这很愚蠢）。TFS2010 还允许您更改共享点项目位置，而不是使用 TFS2008 那些糟糕的子文件夹。TFS2010 还具有燃尽图等对于项目管理非常有用的工具。就好像TFS2010是为包括客户在内的整个制作团队准备的！但它仍然花费太多:(
另请记住，TFS 需要服务器硬件提供更多的马力。当然，至少要有一个 Windows 服务器许可证。
正如我们公司所遵循的，最佳实践是使用 2 台服务器：前端（带有集成的共享点），后端有一个专用的sql服务器（我们使用企业集群）。TFS 可以安装在一台机器上，但不应该。
相比之下，我们的 svn 服务器安装在具有 256mb ram 和 1 个 cpu 的虚拟 Linux 服务器上，并且在执行 checkout-all 等常见任务时仍然快了几个数量级。虚拟硬件是 vshpere 可以分配的最低配置！不过磁盘速度很快（SAN）。
我建议 TFS 需要至少 5000 美元的专用硬件，而 svn 服务器（在 Linux 上）可以与任何对于当前基于 Windows 的操作系统来说已经过时的硬件运行。
我认为这取决于项目完成的情况和环境。如果您只有一个简单的小型项目，那么 SVN 就很棒。正如一些人所写的，VisualSVN 可以很好地集成到 Visual Studio s.t 中。您不必通过本机文件系统进行签入/签出。
TFS 非常适合版本控制，但如果您真正使用它的所有功能，效果会更好。在我看来，如果您使用工作项作为集成存储库来处理客户错误报告、新功能请求以及通过管理任务和相应的估计时间、使用时间和时间来跟踪项目进度，那么这确实是值得的。剩余时间指示。
真正有趣的是使用将工作项与源代码签入相关联的功能。看 这里 了解更多相关信息。
我们是一个正在从 SVN 迁移到 TFS2010 的小团队。我们这样做的最大原因是 Visual Studio 和用于错误跟踪的 WebAccess 的集成，它现在是 TFS 的一部分。
@亚当：希望我们会有更好的体验。还不能说...
我在过去 3 年里一直使用 SVN（之前使用的是 VSS），最近不得不切换到 TFS2010。总体感觉是它比 SVN 更容易出错，除了与任务/bug 的良好集成之外，我不认为它比 SVN 有优势。速度似乎也比SVN慢一些。
如果我现在选择源代码管理，我仍然会选择 SVN。
关于工具：-ANKHSVN Visual Studio插件与TFS源控制一样好 - 乌龟比TFS对应物好得多
如果您不需要非开发人员来处理问题，TFS 就很棒。
我们的服务台需要参与这个过程，但它只是没有削减它。
另外，至少 tfs 2005 中的构建管理很糟糕，甚至无法与 2008 slns 相比进行构建。我真的不喜欢我的源代码控制选择，影响我的部署选择，这就是为什么我的团队不是 svn 商店。
如果它 只是 基于源代码控制，我会选择 SVN。Visual Studio 的 AnkhSVN 免费插件在其新版本中得到了极大的改进。此外，您还可以获得 SVN 的源代码，并且文档非常棒！他们改变了 一些神秘的东西 在 TFS 2010 源代码控制中，如果没有源代码，排除故障可能会非常困难。另外，您还需要依赖 MSDN 团队来提供文档，他们会按照自己的时间表和深度进行制作。
话虽如此， TFS 显然提供的不仅仅是源代码控制. 。它是一个 ALM 工具。将其与工作项目、报告、自动化构建相结合， 门禁办理登机手续, 、自动化测试等可以提供一些非常丰富的价值，而这些价值只有通过使用 SVN 连接不同的工具才能获得。当然，拥有 SVN 源代码并不是万无一失的。我遇到过使用 SVN 的情况，仍然需要数周时间才能完全弄清楚发生了什么。
因此，我建议您从 ALM 的角度来看待它，看看您的公司是否会使用 所有 TFS 功能 或者将采用最佳策略（例如吉拉）。
TFS 领先一英里。
我无意中使用 SVN 基于文件的方法给自己带来了太多问题。我经历过的源代码控制问题：TFS - 2年中的0个问题 - 损失数量...
是的，我知道 TFS 的价格对大多数公司来说都是一个因素，这真是太遗憾了。如果微软有一个合理的定价模型，他们可能会拥有更多的市场份额（和利润）。
