SVN与Team Foundation Server [已关闭]

Question

几个月前，我的团队将源代码控制从Visual SourceSafe切换到Apache Subversion ，我们并不高兴。

最近我一直在关注Team Foundation Server ，至少从表面上看，它看起来非常令人印象深刻。 与Visual Studio有很好的集成，为DBA，测试人员，项目经理等提供了许多出色的工具。

这两种产品最明显的区别在于价格。 Apache Subversion（免费）很难打败。 Team Foundation Server非常昂贵，因此额外的功能真的必须将Subversion放入裤子中。

• 有没有人有这方面的实践经验？
• 他们如何比较？
• Team Foundation Server真的值得花费吗？

Answer 1

以下是两者之间最大的区别，我用过两者：

1） TFS与开发的“Visual Studio方式”紧密耦合。 这并不是说TFS与VS IDE紧密耦合，这意味着TFS很难保持熟悉的“签入”/“签出”范例的Visual SourceSafe，即使它真的不再是一个合适的模型。 当你的开发人员可能花时间与网络断开连接时，Subversion的“提交”/“更新”概念会更加真实。 TFS希望开发人员始终连接到服务器。 这是一个很大的减号。 我个人觉得TFS对于文件在服务器和本地磁盘上的组织方式不太透明，因为Visual Studio集成很紧密。 甚至TFS的更大支持者也承认，其连接的签入/签出模型对于断开连接的开发人员来说并不是一个令人信服的选择。 在人们开始关注SVN选项（如git和Mercurial而不是SVN）的情况下，TFS的“结账”模型看起来有点像恐龙。

2） 成本。 那些说TFS不贵的人可能是非常小的商店，或者不符合TFS的许可条款。 您需要一个客户端访问许可证，以便在您执 你是一个管理错误的经理吗？ 您需要〜$ 250 CAL（零售TFS许可证中包含5个）。 想要报告问题的业务用户？ 250美元的CAL。 开发人员？ 250美元（除非他们有MSDN，在这种情况下它包括在内）。 服务器？ 500美元（如果您有MSDN，则包括在内）。 当然，向你出售TFS副本的人会告诉你工作项跟踪对于其他用户是免费的，但是这些额外的用户只能看到他们自己创建的工作项，而不是整个团队的工作项，这不是在面向团队的敏捷环境中太有用了。 当你拥有一个中等规模的组织时，所有这一切都会增加，当SVN和CruiseControl.net的增量成本为0美元这么多的最佳产品时，很难证明这一点。 （但是，对于TFS的公平性，我还在等待一个非常好的OSS问题跟踪器）

3） 项目结构。 在项目数量较少的大型团队中，TFS可能会运作良好。 如果您内部有许多小型，未连接或松散连接的业务线应用程序，TFS的结构可能开始变得霸道。 首先，不可能自己定义项目的分类 - 您可以在项目中设置“区域”，但是在“项目”的基本上下文中一起跟踪所有问题和文档。 创建新的“项目”通常是耗时的，并且对于小的努力来说是过度的。 当然，SVN没有任何类型，因为它只关注源代码控制，但如果你需要良好的小项目灵活性，SVN和另一个问题跟踪工具可能是更好的选择。

我认为，值得：

• 对于拥有大量预算良好项目的大型团队而言，在开发人员几乎完全在IDE中工作的微软商店中，TFS就是赢家。 当您需要在项目中集中执行策略时，TFS也会获胜。

• 对于许多小型团队，有许多不同的，较小的项目，或成本问题的商店，或者开发人员与源代码控制断开连接的团队，请使用SVN。

Answer 2

我很惊讶过去使用Subversion的人甚至对TFS源代码控制有需求。

我对TFS（2005）的经历非常可怕。 我已经阅读了各种白皮书和指导，了解如何根据各种开发需求正确构建源代码。

我们的简单情况，我们有主干线开发的主干，我们整合变更和部署的集成分支，以及跟踪过去版本的发布分支是非常常见和直接的，但我们不断遇到问题。

我对TFS的主要问题：

• 与subversion相比，合并是一个PAIN。
• 有不固定的错误。 我遇到了一个关于重命名/合并的问题，这个问题已经有2年的历史了，并且2005年将永远不会发布修复程序。我们最终将我们的分支移动到“破损”文件夹，我们现在忽略它。
• 在文件上放置只读锁定是一种摩擦。 谁说我需要编辑批处理文件并在TFS内部构建脚本，以便它为我“检查”？ Subversion 知道哪些文件发生了变化。 那里没有只读锁。
• 速度。 TFS在WAN上速度慢，而且只有当我将VPN连接到我的工作计算机时它才真正可用，这使得我的开发体验整体上非常缓慢。
• 缺乏良好的命令行和资源管理器集成。 IDE集成非常适合日常的Get-Latest，添加文件和签入，但是当您需要在许多项目中执行操作时，可以随意使用好的工具。 在有人跳下我的喉咙声称tf.exe运行良好之前......它不是真正的cmd线工具。 例如，检入代码不应弹出模态对话框。

......列表还在继续。 我认为即使有了所有的整合，也有更好的免费替代方案。

Answer 3

我最近加入了CodePlex的开源项目。 他们使用TFS进行源代码控制，我不得不说它非常棒。 到目前为止，我对它印象深刻。 我是IDE集成的忠实粉丝，分支和标记代码是多么容易。 如果您已经正确配置了所有内容，那么添加一个源代码控制解决方案就像两次点击一样。

现在。 是否值得高昂的价格标签？ 我不这么认为。 在CodePlex项目上工作的好处是，它让我可以获得我需要的TFS体验，如果我以后必须在某个地方使用它。 如果您希望源控件具有良好的IDE集成，请使用VisualSVN集成包。 获得许多相同的功能（在非域计算机BTW上免费）是一个非常便宜的投资。

Answer 4

我们是VS.NET商店，我们实施了：

1. 问题跟踪的Bugzilla
2. Apache Subversion作为源代码存储库后端
3. VisualSVN Server用于管理服务器上的SVN
4. 客户端上的TortoiseSVN （在Windows资源管理器中）和AhnkSVN或VisualSVN （在Visual Studio中）
5. CruiseControl.NET用于自动构建

费用：0美元优惠：无价

如果您是一个小团队，或者还没有准备好购买TFS流程，那么SVN和开源工具就是您的选择。

Answer 5

正如其他人所指出的那样，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特征大致相同。 他们都进行分支和合并，两者都进行原子签入，它们都支持重命名和移动。 我认为对于刚开始使用分支和合并概念的人来说，在Source Control Explorer中看到分支是很好的。

TFS真的不那么贵（可能是1200美元？）。 或许与SVN相比。 与报表服务和SharePoint的集成很不错，但同样，如果您不使用它，那么无关紧要。

我要说的是下载TFS的180天试用版并试一试。 并排进行试验。 无论你走哪条路，我都觉得你会很开心。

Answer 6

正如Ubiguchi所指出的，TFS不是版本控制产品。 购买TFS只是为了将其用于版本控制，显然是浪费金钱。 TFS是一个集成的工具套件，用于自动化应用程序生命周期管理的所有方面（并且几乎适用于“企业”）。

根据Ben S的帖子 - 我不明白你对锁的评论。 TFS根本不需要锁。 管理员可以将TFS配置为像VSS（一些“不明智的”客户所要求的功能）一样工作到“结账时获取最新”，我相信它也会执行结账锁定。

但是通过“正常”使用TFS，“签出”会提示用户输入锁定类型 - 默认值应为“无”。 用户可以选择签出（或签到锁定） - 但不是必需的。 如果您不想要锁，请不要使用它们。

TFS会跟踪哪些用户在服务器上检查出于各种性能原因（更快地获取最新信息）和项目管理（我喜欢看看开发人员检查了哪些文件以及他们的结账时间有多长）。

我并不是真的熟悉SVN（我从来没有使用过它） - 所以我不能评论“合并对TFS的影响更糟” - 而且没有遇到Ben S报道的合并错误 - 但我已经很棒了使用TFS进行分支和合并的成功。

我知道一个用例TFS对于经常“离线”的用户来说仍然相当薄弱。 TFS是一种“服务器产品”，它假定用户在大多数时间都是连接的。 2008年版本的离线体验有所改善（2005年令人沮丧）但仍有很长的路要走。 如果您的开发人员需要（或希望）经常长时间与网络断开连接 - 您最好使用SVN。

使用TFS的SVN粉丝需要考虑的另一个特性是SVN Bridge是一个码本，它允许用户使用TortiseSVN连接到TFS。 我的好朋友和我的同事广泛使用它并喜欢它。

关于缺少命令行的评论让我感到惊讶 - 命令行工具很广泛（尽管许多需要单独下载TFS Power Tools

我怀疑Ben的评论是基于2005版本的评估，这显然是“Microsoft V1.0”产品。 该产品目前处于2.1版本，不久的将来会推出第3版。

Answer 7

TFS很令人发指。 此时我使用SVN（带有Live Mesh进行备份）在本地进行版本控制，因为我在TFS上遇到了很多问题。 主要问题是TFS使用时间戳来记录您是否拥有最新版本，并将这些时间戳存储在服务器上。 您可以删除本地副本，从TFS获取最新版本，并且它会说所有文件都是最新的。 这是一个愚蠢的系统，无法保证您拥有正确的文件版本。 这导致了许多烦恼：

• 编辑任何文件时都需要通知TFS，因此您需要始终连接到服务器。
• 如果您编辑IDE之外的文件，TFS会感到困惑。 此外，它将所有文件设置为NTFS中的只读文件。

虽然TFS支持合并，但它确实是一个签入/签出系统。 如果编辑文件，通常会发现它已锁定到其他开发人员。 有各种各样的方法，但系统是如此令人费解，你将永远遇到问题。 例如，我们的开发人员发现他们可以通过检查整个解决方案来解决在NTFS中设置为只读的所有文件，这会对所有文件设置独占锁定。 我这样做了几次因为subversion具有相同的checkout语法，它没有获得锁定。

最后，团队资源管理器（客户端）高达400 MB，TFS服务器需要SharePoint，需要两天时间才能安装。 颠覆一键安装程序大约30 MB，它将在一分钟内为您安装服务器。 TFS有许多功能，但它的基础是如此不稳定，你永远不会使用或关心它们。 TFS在许可证方面是昂贵的，并且在开发人员将浪费在stackoverflow上而不是编写代码的时候：P

Answer 8

我的建议，Team System不值钱。 我已经使用了两个和使用Team System后，我试图找到一个类似的替代品。 基本上你所支付的是集成，你可以争论自定义支持，但我已经能够用一点时间创建一个Team System替换，并将工具集成在一起。

我最近问了一个问题 ，其他人做了什么来提出一个Team System替代方案。 我还列出了用于创建替换的开发工具。 希望通过这个答案和我提出的问题，你可以找到对你有用的东西。

我不是团队系统的仇恨者，我只是觉得这不值钱。 这是一个非常好的工具，如果你不介意为它付出代价，那么一定要用它。 这就是我创造替代品的全部原因。 我想要Team System提供的功能。

Answer 9

这是一个名为Ankhsvn的VisualSVN的开源版本。 现在，使用它已经完成了它的好处。

Answer 10

如果你需要的只是源代码控制，那么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更有可能成为一个不错的选择。

Answer 11

我在工作和家里都使用过。 它们本身都非常酷。 我建议使用TFS的唯一一次是，如果你将使用更多的功能，而不仅仅是源代码控制。 如果您需要的只是源代码控制，那么您无法使用SVN，这就是原因。

1. VisualSVN Server这是一个完整的SVN服务器，有一个很好的插件来管理它。 它允许您通过UI使用Windows身份验证。 简单。

2. 乌龟它的乌龟，足够说。

3. ankhsvn这是一个很棒的SCC插件。 对于那些想要完全VS IDE集成的人来说，最新版本是一个完整的SCC插件。 因此，您现在可以免费获得完全集成。

以上设置是100％免费的，可以帮助您完成源控制所需的任何操作。

Answer 12

TFS不只是源控制。 如果您使用TFS提供的整个软件包，错误跟踪，构建，报告等，那么TFS是一个非常可靠的选择（当然比Rational更好）。 TFS还与Active Directory很好地集成。

虽然如果你只是谈论SCM，那么我更喜欢SubVersion。 我真的不喜欢IDE集成。 我也喜欢SVN的Trunk / Tags / Branches结构的约定，以及在分支之间切换的相对容易性。 但是在TFS中合并似乎更容易。 Tortoise的UI虽然打败了TFS，但特别是在向repo添加文件方面。

Answer 13

我正在开展一个有5个人的项目，我们最近从SVN切换到了TFS。 整个过程一直是个噩梦。 我们有来自XMLSpy的自动生成代码，而TFS无法识别在VS2008之外修改的文件。 TFS电动工具可以扫描您的结账并解决此问题，但必须记住使用这些工具是一件痛苦的事。 我们经常遇到的另一个问题是TFS中的默认合并工具。 它是迄今为止我用过的最糟糕的合并工具。 有人会认为TFS能够处理基本的解决方案合并，但到目前为止并非如此。

内置的用户界面非常有用，但它也有缺陷。 如果我从我的解决方案资源管理器中签出，有时已添加的文件未签出。 如果我从Team Source Control窗口执行此操作，则可以完美运行。 这是为什么？ 我期待VS2010中的TFS，因为我听说过它很棒，而且SVN远非完美，但我希望其中一些功能能够更加直观地运行。

亚当

Answer 14

广泛使用这两个，我认为Wedge注意到“TFS包括错误跟踪，工作项跟踪和源代码控制以外的其他功能”。

但是，我可以诚实地说SVN和TFS在可伸缩性方面似乎相当，如果SVN的源控制由于其固有的简单性而在TFS上具有优势。

如果你想要你的源代码控制旁边的工作项和错误跟踪，那么你要么去TFS，要么你去SVN和其他一些可能免费的工具，比如bugzilla。 虽然TFS确实将源代码控制和工作项跟踪集成在一起，但我真的认为MS应该免费赠送它作为多年来虐待这么多开发人员的道歉。

Answer 15

我说这真的取决于你的需求。 TFS非常好，我已经广泛使用它，但它非常瞄准企业级，如果你不需要所有这些功能，它可能没有必要。 如果你确实需要这些功能（特别是分支，可扩展性，工作项跟踪等），那么每一分钱都值得。 请记住，TFS包括错误跟踪，工作项跟踪和源代码管理之外的其他功能。 如果您有多个分支，或者如果您发现自己在Subversion中遇到一些功能缺乏或其他问题，那么切换可能是个好主意。 但是，除非有充分的理由转换，否则应该可以避免切换源控制系统的成本和生产率。

Answer 16

TFS非常适合项目管理和跟踪，但我觉得源代码控制不如SVN。 这是我的TFS牛肉：

入住/退房模型

这对TFS源控制来说是一个巨大的影响。 不幸的是，VS会自动为您检查项目，即使您不想这样做。 我一直在某人检查了一些文件，然后去度假。 我负责重组目录结构，但是因为一大堆文件已经签出给那个人而无法完成。 GUI中无法撤消签出，这意味着必须在命令行中逐个完成。 或者我必须弄清楚如何为此编写一个power shell脚本。

VS需要做任何事情

有时我想编辑一个文本文件并将其签入。这需要我启动VS 2010，这是一个巨大的野兽，只需编辑一个文件并检查它。使用SVN需要几秒钟的东西现在需要我一分钟。

正如其他人指出的那样，如果文件没有签出，则文件会被标记为只读。 如果你使它可写并在VS之外编辑它，TFS将无法识别它。 这使得编辑VS之外的东西很烦人。 这意味着，启动VS，检出文件，编辑另一个编辑器，在VS中检入。

SVN中的一些操作现在很麻烦

• 也许我还没想出来，但我发现回滚变更集对于TFS非常繁琐。

• 将文件添加到源代码管理中（这不是解决方案的一部分）是一个巨大的痛苦。 TFS源代码控制资源管理器只显示哪些文件在源代码控制中，而不是哪些文件不在哪里（可能在某处设置了这个，我不知道）。 使用Tortoise SVN，我可以简单地按一个文件夹上的Commit并选择要添加的文件。

Answer 17

我使用过SVN和TFS。 使用TFS的主要优点是它与Visual Studio紧密集成。 错误跟踪，任务跟踪都将在一个地方进行。 为这些项目生成的报告将帮助利益相关者随时了解项目状态。

Answer 18

我目前正在领导我的公司针对Rational Suite评估TFS的工作，这是我们目前使用的。 到目前为止，TFS 2008正在推出clearcase + clearquest。 开发环境集成是它真正闪耀的地方。

Answer 19

我的10美分：

TFS2005是一个笑话 - 很难安装，甚至更难维护TFS2008稳定 - 更容易安装，更简单的维护和自动化构建工作。 TFS2010是EPIC！ - 安装是狗eassssyyy。 管理非常简单; 这是一个很好的布局UI。 将它与VS2008集成并不是那么容易，因为你无法在vs2008中创建项目，你必须使用vs2010（这是愚蠢的）。 TFS2010还允许您更改sharepoint项目位置，而不是拥有TFS2008的那些可怕的子文件夹。 TFS2010还具有类似于燃尽图的工具，这对于项目管理非常有用。 就像TFS2010适用于包括客户在内的整个生产团队！ 虽然它仍然花费太多:(

Answer 20

还要记住，TFS需要来自服务器硬件的更多马力。 至少有一个Windows服务器许可证。

正如我们公司所遵循的那样，最佳实践是使用2台服务器：前端（带有集成的sharepoint）和后端的专用sql服务器（我们使用企业集群）。 TFS可以安装在1台机器上，但不应该安装。

在比较中，我们的svn服务器安装在具有256mb ram和1 cpu的虚拟linux服务器上，并且在执行像checkout-all这样的常见任务时仍然快几个级别。 虚拟硬件是最低的vshpere可以分配！ 磁盘速度很快（SAN）。

我建议TFS需要至少5000美元的专用硬件，而svn服务器（在Linux上）可以运行任何对于当前基于Windows的操作系统已经过时的硬件。

Answer 21

我在过去的3年中使用过SVN（早先来自VSS），最近不得不切换到TFS2010。 总的感觉是它比SVN更吵，除了与任务/错误的良好集成之外我不认为它对SVN有优势。 速度似乎也比SVN慢一些。

如果我现在选择一个sourcecontrol，我仍然会选择SVN。

关于工具： - AnkhSVN Visual Studio插件与TFS源代码控件一样好 - Tortoise比TFS对手好多了

Answer 22

在我看来，这取决于项目完成的情况和环境。 如果您只有一个简单的小项目，那么SVN就很棒。 正如已经写过的那样，VisualSVN很好地集成到Visual Studio中，您无需在本机文件系统上进行签入/签出。

TFS非常适合版本控制，但如果您真正使用它的所有功能，那就更好了。 在我看来，如果您使用（例如）工作项作为您的集成存储库来处理客户错误报告，新功能请求以及通过管理任务跟踪项目进度以及相应的估计时间，使用时间和剩余时间指示。
真正有趣的是使用将工作项与源代码签入相关联的功能。 在此处查看有关此内容的更多信息。

Answer 23

我们是一个从SVN迁移到TFS2010的小团队。 我们这样做的最大原因是Visual Studio中的集成和用于错误跟踪的WebAccess，现在是TFS的一部分。

@Adam：希望我们能有更好的体验。 还不知道......

Answer 24

如果它只是基于源代码控制，我会选择SVN。 Visual Studio的AnkhSVN免费加载项在其新版本中得到了极大的改进。 此外，您获得了SVN的源代码，文档很棒！ 他们在TFS 2010源代码管理中改变了一些神秘的东西 ，如果没有源代码，那么排除故障可能会非常艰巨。 此外，您依赖于MSDN团队来提取文档，并且他们按照自己的时间表和自己的深度来完成。

话虽如此， TFS显然提供的不仅仅是源代码控制 。 它是一个ALM工具。 将其与工作项，报告，自动构建， 门控签入 ，自动化测试等结合起来可以提供一些非常丰富的价值，只有通过连接不同的SVN工具才能获得这些价值。 当然，拥有SVN的源不是故障保护。 我已经进入了SVN的场景，它仍然需要数周才能完全弄清楚发生了什么。

因此，我建议您从ALM的角度来看一下，看看您的公司是要使用所有TFS功能还是采用最佳策略（例如JIRA）。

Answer 25

如果你不需要非开发人员，那么TFS很棒，可以获得下午的东西。

我们的服务台需要参与这个过程，而且它并没有削减它。

至少tfs 2005中的构建管理是非常有意义的，它甚至无法构建vs 2008 slns。 我真的不喜欢我的源代码控制选择，影响我的部署选择，这就是为什么我的团队不是一个svn商店。

Answer 26

TFS一英里。

我无意中使用SVNs基于文件的方法给自己造成了太多问题。 我遇到的源控制问题：2年以上的TFS-0问题SVN - 丢失数量......

是的，我知道TFS的价格对大多数公司来说都是如此，这是一种耻辱。 如果他们有合理的定价模型，MS可能会有更多的市场份额（和利润）。