SVN vs. Team Foundation Server
几个月前，我们的团队把我们的源代码控制权从Visual SourceSafe切换到了Apache Subversion ，我们并没有更高兴。
最近我一直在关注Team Foundation Server ，至less在表面上看起来非常令人印象深刻。 与Visual Studio有一些很好的集成，并为DBA，testing人员，项目经理等提供了许多有用的工具。
这两款产品最明显的区别就是价格。 很难打败Apache Subversion（免费）。 团队基础服务器是相当昂贵的，所以额外的function将真的要踢裤子的Subversion。
- 有没有人有两个实际经验？
- 他们如何比较？
- Team Foundation Server真的值得吗？
我最近在CodePlex上join了一个开源项目。 他们使用TFS来控制源代码，我不得不说这绝对是macros伟的。 到目前为止，我对它印象深刻。 我是IDE集成的忠实粉丝，分支和标记代码是多么容易。 如果您已经正确configuration了所有内容，则向源代码控制添加解决scheme就像是双击。
现在。 这是值得沉重的价格标签？ 我不这么认为。 在CodePlex上处理项目的好处是可以让我获得我需要的TFS体验，以便稍后在某个地方使用。 如果你想为你的源代码控制好IDE集成，去抓VisualSVN集成包。 获得许多相同的function（在非域名计算机上免费）是一个非常便宜得多的投资。
这两个对我来说最大的区别，我用了两个：
1） TFS与开发的“Visual Studio方式”紧密相连。 这并不是说TFS与VS IDE紧密相连，这意味着即使TFS已经不是一个合适的模型，TFS仍然努力保持熟悉的“检入”/“检出”Visual SourceSafe范式。 当你有可能花费时间与networking断开连接的开发人员时，Subversion的“提交”/“更新”的概念更为现实。 TFS希望开发人员始终连接到服务器。 这是一大减。 我个人发现，由于Visual Studio集成严格，TFS对于在服务器和本地磁盘上的文件组织方式不太透明。 即使TFS的更大的支持者也承认，连接检入/检出模式对于断开连接的开发人员来说并不是一个引人注目的select。 在人们开始关注像git和Mercurial之类的DVCS选项的情况下，TFS的“check out”模型看起来有点像恐龙。
2） 成本。 那些说TFS不贵的人可能是非常小的店铺，或者不符合TFS的许可条款。 您需要一个客户端访问许可证，以便在您做任何事 你是一个只pipe理错误的经理吗？ 你需要一个〜$ 250的CAL（零售TFS许可中包含5个）。 一个只想报告问题的商业用户？ 250美元的CAL 开发者？ 250美元（除非他们有MSDN，在这种情况下，它包括在内）。 服务器？ 500美元（包括如果你有MSDN）。 当然，向你销售TFS副本的人会告诉你，工作项目跟踪对于其他用户是免费的，但是这些额外的用户只能看到他们自己创build的工作项目，而不是整个团队的工作项目，在面向团队的敏捷环境中非常有用。 当你拥有一个中等规模的组织时，所有这些都会加起来，而当SVN和CruiseControl.net的增量成本等许多最好的产品都是$ 0时，很难certificate这一点。 （尽pipe公平，但我仍然在等待一个非常好的OSS问题跟踪器）
3） 项目结构。 在项目数量较less的大型团队中，TFS可能会运行良好。 如果你是一些小型的，不连接的或松散连接的业务线应用程序的内部，TFS的结构可能开始变得霸道。 首先，不可能自己定义项目的分类标准 – 你可以在一个项目中设置“区域”，但所有的问题和文档都在“项目”的基本上下文中一起跟踪。 创build新的“项目”往往是耗时的，对于小的努力来说是过度的。 当然，SVN没有什么特别之处，因为它只关注源代码控制，但是如果你需要良好的小项目灵活性，SVN和另一个问题跟踪工具可能是更好的select。
我的意见，为什么它的价值：
-
对于拥有大量预算良好的项目的大型团队而言，在开发人员几乎完全在IDE内工作的微软商店中，TFS是胜利者。 当您需要集中执行项目策略时，TFS也会获胜。
-
对于许多小型团队来说，有许多不同的小型项目，或者成本问题的商店，或者开发人员与源代码pipe理系统断开连接的团队，请与SVN联系。
我很惊讶，以前使用过Subversion的人甚至会对TFS源代码pipe理有所需求。
我对TFS（2005）的经验非常糟糕。 我已阅读了各种白皮书和指导，以便如何正确构build您的来源，满足各种发展需求。
我们简单的情况是，我们有一个主线开发的主干，我们集成更改和部署的集成分支，一个发布分支来跟踪过去的版本是非常普遍和直接的，但是我们不断遇到问题。
我与TFS的主要问题：
- 与颠覆相比，合并是痛苦的。
- 有不确定的错误。 我遇到了一个关于重命名和合并的问题，这个问题已经有两年的时间了，而且一个修复程序也不会在2005年发布。我们最终将分支移动到一个“破损”的文件夹中，现在我们忽略它。
- 把只读锁放在你的文件上就是摩擦。 谁说我需要在TFS中编辑batch file和编译脚本，以便它能“检查出”我？ Subversion 知道哪些文件改变了。 那里没有只读锁。
- 速度。 TFS在广域网上速度很慢，而且只有在我的工作计算机上使用VPN才能使用，这使我的开发经验总体上非常慢。
- 缺乏良好的命令行和资源pipe理器集成。 IDE集成对于Get-Latest日常工作，添加文件和检入非常有用，但是当您需要在许多项目中执行操作时，最好使用好的工具。 而之前有人跳下我的喉咙声称tf.exe运作良好…这不是一个真正的命令行工具。 例如，检入代码不应该popup一个modal dialog。
…名单继续。 我认为，即使是所有的整合，都有自由的select，是远远优于。
我们是一个VS.NET商店，我们实现了：
- Bugzilla进行问题跟踪
- Apache Subversion作为源代码库的后端
- VisualSVN服务器用于pipe理服务器上的SVN
- 客户端上的TortoiseSVN （在Windows资源pipe理器中）和AhnkSVN或VisualSVN （在Visual Studio中）
- CruiseControl.NET用于自动构build
成本：$ 0好处：无价
如果你是一个小团队，或者没有准备好购买谁的TFS过程，SVN和开源工具是要走的路。
正如其他人所指出的，TFS为您提供了更多的function，然后SVN以项目pipe理等forms进行。 使用了两者，并与非常大的公司一起实施TFS，这是我的两分钱。
1）如果你使用TFS 2005，升级到TFS 2008.你会感谢我。 TFS 2008有很多改进，使其可行。
2）如果你住在Visual Studio中，并且你想要集成IDE，那么使用TFS。 我已经使用SVN集成，几乎总是回到使用TortoiseSVN。
3）如果您喜欢将帐户与Windows身份validation集成的想法，请使用TFS。 从这方面来说，可pipe理性很好。 SVN可能存在一些问题 – 我并不积极，但是如果您喜欢GUI驱动的pipe理，TFS很难胜任。
4）如果您需要跟踪指标或有更简单的方法来执行签入策略等事情，请使用TFS。
5）如果你有人不执行它，如果它不是MSFT，去TFS。
6）如果你做的不仅仅是.NET（Java工作，Eclipse等）与SVN。 是的，有非常好的产品（如Teamprise），可以很好地与TFS配合使用。 但是，除非其他语言是你的商店的一小部分，只要坚持使用SVN。
除此之外，两者的SCMfunction大致相同。 他们都分支和合并，都做primefaces检查，他们都支持重命名和移动。 我认为对于刚开始使用分支和合并概念的人来说，在Source Control Explorer中可以看到分支是很好的。
TFS真的不是那么贵（$ 1200也许？）。 也许与SVN相比。 与报告服务和SharePoint的集成是很好的，但是，如果你不使用它，那就没有关系。
我想说的是下载TFS的180天试用版，并且试用一下。 并行试用。 无论你走哪条路，我都觉得你会开心的。
正如Ubiguchi指出，TFS不是版本控制产品。 购买TFS的目的只是为了版本控制，显然是浪费金钱。 TFS是一套集成的工具，可以自动化应用程序生命周期pipe理的各个方面（几乎适合于“企业”）。
也是本S的职位 – 我不明白你对锁的评论。 TFS根本不需要锁。 pipe理员可以configurationTFS像VSS（一些“不明智的”客户所要求的function）工作，“我最好结帐”，我相信也签出锁。
但是，通过“正常”使用TFS，“签出”会提示用户inputlockingtypes – 默认值为“none”。 用户可以select退房（或签入locking） – 但这不是必需的。 如果你不想锁，不要使用它们。
TFS确实跟踪哪些用户在服务器上签出了各种性能原因（让最新版本更快）和项目pipe理（我喜欢看看开发人员检出文件和签出多长时间）。
我不太熟悉SVN（我从来没有用过） – 所以我不能评论说“合并与TFS更糟糕” – 并没有碰到本S报道的合并错误 – 但我已经很好使用TFS进行分支和合并是成功的。
一个用例我知道TFS对于那些经常“离线”的用户来说还是相当薄弱的。 TFS是一个“服务器产品”，假定用户大多数时间连接在一起。 2008年发布的线下体验有所改善（2005年惨淡），但还有很长的路要走。 如果您的开发人员需要（或希望）经常长时间断开与networking的连接，那么您最好使用SVN。
对于使用TFS的SVN爱好者来说，另一个需要考虑的特性是SVN桥接器 ，它允许用户使用TortiseSVN连接到TFS。 我的好朋友和同事广泛使用它，并且喜欢它。
另外，关于缺less命令行的评论令我惊讶 – 命令行工具非常广泛（尽pipe很多都需要单独下载TFS Power Tools
我怀疑本的评论是基于对2005版本的评估，这显然是“微软V1.0”的产品。 该产品目前在2.1版中，第三版即将在不久的将来。
TFS是可恶的。 在这一点上，我使用SVN在本地使用SVN进行版本控制（带有Live Mesh进行备份），因为我在使用TFS时遇到了很多问题。 主要的问题是TFS使用时间戳来logging是否有最新版本，并将这些时间戳存储在服务器上。 你可以删除你的本地副本，从TFS得到最新的，它会说所有的文件是最新的。 这是一个愚蠢的系统，不能保证你有正确的文件版本。 这导致许多烦恼：
- 任何文件编辑时都需要通知TFS，因此您需要随时连接到服务器。
- 如果您编辑IDE以外的文件，TFS会感到困惑。 此外，它将所有文件设置为只读在NTFS中。
虽然TFS支持合并，但它确实是一个签入/签出系统。 如果你编辑一个文件，你会经常发现它被locking到其他开发者。 有办法解决这个问题，但是这个系统太复杂了，你总是会遇到这个问题。 例如，我们的开发人员发现，他们可以通过检查整个解决scheme来设置所有文件的独占锁，从而绕过所有在NTFS中只读的文件。 我这样做了几次，因为subversion具有相同的结帐语法，它不会获得一个锁。
最后，团队资源pipe理器（客户端）是一个巨大的400 MB，TFS服务器需要SharePoint和两天的安装。 颠覆一键安装大约30 MB，它将在一分钟内为您安装服务器。 TFS有很多function，但是它的基础是如此不稳定，你永远不会使用或关心它们。 TFS在许可证方面是昂贵的，而且开发人员浪费在stackoverflow而不是编写代码的时候：P
我的build议，团队系统是不值得的钱。 我已经使用了两个和以后使用团队系统，我试图find一个类似的替代品。 基本上你所付出的是集成，你可以争论定制化的支持，但我已经能够创build一个团队系统replace一点时间和集成工具在一起。
我最近问了一个问题 ，其他人做了什么来提出一个Team System的替代scheme。 我还列出了我用来创buildreplace的开发工具。 希望这个答案和我问的问题，你可以find什么适合你。
我不是一个团队系统仇恨，我只是不认为这是值钱的。 这是一个非常好的工具，如果你不介意为此付出代价，那么一定要用它。 这是我创造替代品的全部原因。 我想要Team System提供的function。
这是一个名为Ankhsvn的VisualSVN的开源版本。 现在合作网已经完成了。
如果你所需要的只是源代码控制，TFS是矫枉过正的。 我以前的雇主之一在他们的企业中有TFS，VSS和Subversion。 我们的企业中没有Active Directory或Exchange Server 2003，因此我们最终在TFS服务器上创build了单独的用户，以便开发人员可以使用它。 我们和Ben Schierman提到的合并问题一样，还有其他一些把我们推向Subversion的错误行为。
无论TFS是否适合您，都将取决于您的预算，开发团队的规模以及可用于configuration/维护解决scheme的时间和人员。 如果您需要TFS提供的其他问题跟踪，工作项目和项目统计function，则可能需要查看其他备选scheme。 像JIRA（来自Atlassian Systems）或Trac等产品与Subversion很好地结合在一起，为项目或项目经理提供了一种低价监pipe。
在一个理想的环境中，使用Active Directory，Exchange Server 2003或更高版本以及存储库的专职人员，TFS更可能是一个不错的select。
我已经在工作和家中都使用过。 他们都是非常酷的自己的权利。 我唯一会推荐使用TFS的是，如果你将使用更多的function，而不仅仅是源代码控制。 如果你所需要的只是源代码控制，那么你就不能在SVN中出错，这就是为什么。
-
VisualSVN服务器这是一个完整的SVN服务器，有一个漂亮的插件来pipe理它。 它可以让你通过用户界面使用Windows身份validation。 简单。
-
乌龟它的乌龟，够说了。
-
ankhsvn这是一个很棒的SCC插件。 对于那些需要完整的VS IDE集成的人来说，最新的版本是一个完整的SCC插件。 所以你现在可以完全免费的整合。
上面的设置是100％免费的，并会让你通过任何你需要的源代码控制。
TFS不只是关于源代码pipe理。 如果您使用TFS提供的整个软件包，错误跟踪，构build，报告等，那么TFS是非常稳固的select（当然比Rational更好）。 TFS也与Active Directory完美集成。
虽然如果你只是谈论SCM，那么我更喜欢SubVersion。 我不太喜欢IDE集成。 我也喜欢SVN的Trunk / Tags / Branches结构，并且在分支之间切换相对容易。 尽pipe在TFS中合并似乎更容易。 乌龟的用户界面击败了TFS的手，特别是关于添加文件到仓库。
我会说这实际上取决于你的需求。 TFS是非常好的，我已经广泛使用它，但它非常针对企业级别，如果你不需要所有这些function，可能没有必要。 如果您确实需要这些function（特别是分支，可扩展性，工作项目跟踪等），那么他们每一分钱都是值得的。 请记住，TFS包括错误跟踪，工作项目跟踪和源代码pipe理之外的其他function。 如果你有多个分支，或者如果你发现自己在Subversion中缺乏特性或其他function，那么切换可能是一个好主意。 但是，除了切换你的好理由之外，应该避免开关源控制系统的成本和生产力。
经过广泛使用后，我认为Wedge注意到“TFS包括错误跟踪，工作项目跟踪和源代码控制之外的其他function”。
不过，我可以诚实地说，SVN和TFS在可伸缩性方面看起来相当平等，如果SVN的源控制由于其固有的简单性而在TFS上有优势。
如果你想在你的源代码控制旁边找工作项目和bug跟踪，那么你要么去TFS，要么去SVN和其他一些可能免费的工具，比如bugzilla。 虽然TFS确实将源代码控制和工作项目跟踪结合在一起，但我真的认为MS应该免费赠送它作为多年来滥用VSS的这么多开发者的道歉。
我已经使用SVN和TFS。 使用TFS的主要优点是与Visual Studio紧密集成。 错误跟踪，任务跟踪将全部在一个地方。 而这些项目的报告将帮助利益相关者了解项目状态。
我正在从事一个有5人的项目，最近我们从SVN切换到TFS。 整个过程一直是一场噩梦。 我们有从XMLSpy自动生成的代码，并且TFS不能识别在VS2008之外修改的文件。 TFS电动工具可以扫描您的结帐，并解决这个问题，但要记住使用这些工具是一个痛苦。 我们经常遇到的另一个问题是TFS中的默认合并工具。 这是迄今为止我使用过的最糟糕的合并工具。 人们会认为，TFS将能够处理基本的解决scheme合并，但迄今为止并非如此。
内置的用户界面非常有用，但也有缺陷。 如果我从我的解决scheme资源pipe理器签出，有时候已添加的文件没有签出。 如果我从“团队源代码pipe理”窗口中执行此操作，则可以完美地工 这是为什么？ 我期待着VS2010中的TFS，因为我已经听到了很多关于SVFS的内容，而SVN并不完美，但是我期望这些function中的一些function更直观一些。
亚当
TFS对项目pipe理和跟踪非常有用，但我觉得源代码控制不如SVN。 这是我的牛肉与TFS：
入住/退房模式
这对于TFS源代码pipe理是一个巨大的贡献。 不幸的是，即使你不想，VS也会自动为你检出物品。 我一直在某个地方查看一些文件，然后去度假。 我负责重组目录结构，但是因为一堆文件被检出给那个人，所以无法进行。 在GUI中没有办法撤消结帐，这意味着它必须在命令行中逐一完成。 或者我必须弄清楚如何为此编写一个power shell脚本。
VS需要做的一切
有时我想编辑一个文本文件并检查它。这要求我启动VS 2010，这是一个巨大的野兽，只是编辑一个文件，并检查它。SVN花了几秒钟的东西现在需要我一分钟。
正如其他人指出的那样，文件只有在没有签出时才被标记为只读。 如果你在VS之外编写它，TFS将不会识别它。 这使得在VS之外编辑一些恼人的东西。 这意味着，启动VS，检出文件，编辑另一个编辑器，检入VS.
SVN中的一些操作很简单，现在很痛苦
-
也许我还没有弄明白，但是我发现TFS回滚一个变更是非常繁琐的。
-
将文件添加到源代码pipe理，这不是一个解决scheme的一部分，是一个巨大的痛苦。 TFS源代码pipe理资源pipe理器只显示哪些文件在源代码控制中，哪些不是（可能有某个地方的设置，我不知道）。 用龟SVN，我可以简单地按下一个文件夹上的提交，并select要添加的文件。
我目前正在领导我的公司针对我们目前使用的Rational Suite来评估TFS。 到目前为止，TFS 2008正在变得清晰明确。 开发环境的整合是真正闪耀的地方。
我的10美分：
TFS2005是一个笑话 – 难以安装，甚至更难以维护TFS2008是稳定的 – 更容易安装，更简单的维护，和自动化的构build工作。 TFS2010是EPIC！ – 安装是狗eassssyyy。 pipe理很容易， 这都是一个很好的UI。 与VS2008集成并不是那么容易，因为你不能在vs2008中创build项目，你必须使用vs2010（这是愚蠢的）。 TFS2010还允许您更改共享点项目位置，而不是有TFS2008这些可怕的子文件夹。 TFS2010也有像烧毁图表这样的工具，对项目pipe理非常有用。 这就像TFS2010是包括客户在内的整个生产团队！ 它仍然花费太多，虽然:(
另外请记住，TFS需要从服务器硬件中获得更多的马力。 而且至less有一个windows服务器许可证的课程。
正如我们公司所遵循的，最佳做法是使用2台服务器：前端（带有集成的共享点）和后端专用的SQL服务器（我们使用企业集群）。 TFS可以安装在1台机器上，但不应该安装。
比较起来，我们的svn服务器安装在一个256MB ram和1个cpu的虚拟linux服务器上，在执行checkout-all等常见任务时，速度仍然快了几个数量级。 虚拟硬件是最低的vshpere可以分配！ 磁盘虽然很快（SAN）。
我build议TFS需要至less5000美元的专用硬件，而svn服务器（Linux上）可以运行任何硬件，这是当前基于Windows的操作系统的过时。
在我看来，这取决于项目完成的情况和环境。 如果你只是一个简单的小项目，那么SVN是伟大的。 正如已经有人写道，VisualSVN很好地集成到Visual Studio中，您不必在本机文件系统上执行签入/签出操作。
TFS对于版本控制来说是非常好的，但是如果你真的使用了所有的function，那就更好了。 在我看来，如果您使用工作项目作为集成存储库来处理客户错误报告，新function请求以及通过pipe理任务和相应的预计时间，使用时间和剩余时间指示。
还有一点非常有趣的是使用将工作项与源代码签入关联的function。 在这里看到更多的信息。
我们是一个从SVN迁移到TFS2010的小团队。 我们这样做的最大原因是Visual Studio中的集成和错误跟踪的WebAccess，现在是TFS的一部分。
@亚当：希望我们会有更好的经验。 现在还不知道…
过去3年来我使用SVN（早些时候来自VSS），最近不得不切换到TFS2010。 总的感觉是，它比SVN更笨，除了与任务/错误的良好集成，我不认为它有与SVN的边缘。 速度似乎也比SVN慢一些。
如果我现在select一个sourcecontrol，我仍然会使用SVN。
关于工具： – AnkhSVN Visual Studio插件与TFS源代码控件一样好 – 龟TAS比TFS好得多
TFS是伟大的，如果你不需要非开发人员，去下午的东西。
我们的帮助台需要参与到这个过程中，而不是在削减。
而且至less在tfs 2005中的构buildpipe理是非常激烈的，它甚至不能构buildvs 2008 slns。 我真的不喜欢我的源代码控制select，影响我的部署select，这就是为什么我的团队不是一个svn商店。
如果它只是基于源代码pipe理，我会去与SVN。 用于Visual Studio的AnkhSVN免费加载项在其新版本中得到了很大的改进。 另外，你得到了SVN的源代码，文档非常棒！ 他们改变了 TFS 2010源代码pipe理中的一些神秘的东西 ，没有源代码，可以非常艰难地排除故障。 此外，您依赖于MSDN团队抽出文档，他们按照自己的时间表和自己的深度执行操作。
这就是说， TFS明显提供了比源控制更多的东西 。 这是一个ALM工具。 将它与工作项目，报告，自动构build， 门控签入 ，自动化testing等相结合，可以提供一些非常丰富的价值，只有将不同的工具与SVN连接才能获得。 当然，拥有SVN的来源并不是一个安全的保障。 我已经与SVN的情况下，它仍然需要几个星期来完全弄清楚发生了什么事情。
所以，我build议你从ALM的angular度来看待它，看你的公司是要使用所有的TFSfunction，还是要采用最好的策略（如JIRA）。
TFS一英里。
SVNs基于文件的方法，我无意中造成了太多的问题。 源代码pipe理问题经验丰富：2年的TFS – 0问题SVN – 丢失计数…
是的，我知道TFS的价格对大多数公司来说都是如此的耻辱。 如果他们有一个合理的定价模式，MS可能会有更多的市场份额（和利润）。
