几个月前，我的团队将源代码控制从Visual SourceSafe切换到了Apache Subversion，我们从此不再快乐。

最近，我一直在研究Team Foundation Server，至少从表面上看，它似乎非常令人印象深刻。与Visual Studio的集成非常紧密，并且为DBA，测试人员，项目经理等提供了许多出色的工具。

这两种产品之间最明显的区别是价格。很难击败Apache Subversion(免费)。 Team Foundation Server非常昂贵，因此额外的功能实际上必须使Subversion脱颖而出。

• 有人有实践经验吗？
• 他们如何比较？
• Team Foundation Server实际值得花费吗？

解决方案

回答

我最近在CodePlex加入了一个开源项目。他们使用TFS进行源代码控制，我不得不说这是绝对宏伟的。到目前为止，我对此印象深刻。我是IDE集成的忠实拥护者，它对代码进行分支和标记非常容易。如果已经正确配置了所有内容，则向源代码管理添加解决方案就像单击两次。

现在。值得高昂的价格吗？我不这么认为。在CodePlex上进行项目的好处是，它使我获得了所需的TFS经验，以备日后在某个地方使用它时使用。如果我们希望对源代码管理进行良好的IDE集成，请获取VisualSVN集成包。要获得许多相同的功能(在非域计算机BTW上免费)，这是一笔便宜得多的投资。

回答

我说这真的取决于需求。 TFS非常好，我已经广泛使用了它，但是它非常针对于企业级，如果我们不需要所有这些功能，则可能没有必要。如果我们确实需要这些功能(特别是分支，可伸缩性，工作项跟踪等)，那么它们一分钱都值得。请记住，TFS包括错误跟踪，工作项跟踪和源代码控制之外的其他功能。如果我们有多个分支，或者发现自己在Subversion中缺少某些功能或者其他功能，那么切换是个好主意。但是，除非有充分的理由进行切换，否则我们应该避免切换源代码控制系统在成本和生产率上造成的损失。

回答

我的建议是，Team System不值得。我已经使用过这两个功能，并且在使用Team System之后，我试图找到一个类似的替代产品。基本上，我们需要支付的费用是集成费用，并且可以争论定制支持，但是我能够花一​​点时间创建一个Team System替换并将工具集成在一起。

我最近问了一个问题，关于其他人为提出团队系统替代方案所做的工作。我还列出了用于创建替代品的开发工具。希望有了这个答案和我提出的问题，我们可以找到最适合自己的方法。

我不是一个讨厌Team System的人，我只是认为这不值钱。这是一个非常不错的工具，如果我们不介意为此付出代价，那么请务必使用它。这是我创造出我想出的替代产品的全部原因。我想要提供团队系统功能。

回答

广泛使用这两种方法后，我认为Wedge注意到了" TFS包括错误跟踪，工作项跟踪和源代码控制之外的其他功能"，这是值得的。

但是，老实说，就可伸缩性而言，SVN和TFS似乎相当相等，并且由于其固有的简单性，SVN的源代码控制在TFS方面具有优势。

如果我们希望在源代码管理中同时进行工作项和错误跟踪，则可以选择TFS，也可以使用SVN和其他一些可能免费的工具，例如bugzilla。尽管TFS确实将源代码控制和工作项目跟踪集成在一起，但老实说，MS多年来应该免费赠送它作为道歉，以滥用VSS的众多开发人员。

回答

令我惊讶的是，过去曾经使用Subversion的人甚至对TFS源代码控制有需求。

我在TFS(2005)上的经历非常糟糕。我已经阅读了各种白皮书和指南，以了解如何正确地构建源以满足各种开发需求。

在简单的情况下，我们有一个主干开发干线，还有一个集成分支，从中集成更改并从中进行部署，还有一个发布分支来跟踪过去的发布，这是非常普遍和直接的，但是我们一直在遇到问题。

我与TFS的主要问题：

• 与颠覆相比，合并是一个痛苦。
• 有未修复的错误。我遇到了有关重命名/合并的知识，这已经有2年了，而修复程序永远不会在2005年发布。我们最终将分支移动到"损坏的"文件夹，现在我们忽略了它。
• 在文件上放置只读锁很麻烦。谁说我需要在TFS内编辑批处理文件并构建脚本，以便它可以为我"检出"？ Subversion知道哪些文件已更改。那里没有只读锁。
• 速度。 TFS在WAN上速度很慢，并且只有在我将VPN接入我的工作计算机时，它才真正可用，这使我的开发经验总体上确实很慢。
• 缺少良好的命令行和资源管理器集成。 IDE集成非常适合日常Get-Latest，添加文件和签入，但是当我们需要在多个项目中进行操作时，可以使用好的工具就很好。在有人跳下我的嗓子之前，声称tf.exe可以正常工作……这实际上不是cmd线工具。例如，签入代码不应弹出模式对话框。

...清单继续。我认为，即使进行了所有的集成，也有许多免费的替代方案，它们的优势更为明显。

回答

这是VisualSVN的开源版本，称为Ankhsvn。
现在，collabnet接管了它，这要好得多。

回答

TFS不仅与源代码管理有关。如果我们使用TFS提供的整个程序包，错误跟踪，构建，报告等，那么TFS是一个不错的选择(肯定比Rational更好)。 TFS还可以与Active Directory很好地集成。

尽管如果我们只是在谈论SCM，那么我更喜欢SubVersion。我真的不喜欢IDE集成。我也喜欢SVN的Trunk / Tags / Branches结构约定，以及分支之间切换的相对简便性。不过，在TFS中合并似乎更容易。但是，Tortoise的UI击败了TFS，尤其是在向回购添加文件方面。

回答

正如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.

回答

正如其他人指出的那样，与SVN相比，TFS以项目管理等形式为我们提供了更多的功能。这是我的两分钱，在同时使用这两种方法并与大型公司合作实施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天试用版，然后试一试。并排进行试用。我认为无论走哪条路，我们都会感到幸福。

回答

如果我们只需要源代码控制，则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的时间是，如果我们将使用更多的功能，而不仅仅是源代码管理。如果我们需要的只是源代码控制，那么SVN不会出错，这就是原因。

• VisualSVN服务器这是一个完整的SVN服务器，带有用于管理它的不错的插件。它使我们可以直接通过UI使用Windows身份验证。简单。
• 乌龟它的乌龟，足够说。
• ankhsvn这是一个很棒的SCC插件。对于那些想要完全与VS IDE集成的用户，最新版本是完整的SCC插件。因此，我们现在可以免费获得完全集成。

上面的设置是100％免费的，它将完成源代码控制所需的一切。

回答

TFS很棒，如果我们不需要非开发人员，可以使用pm东西。

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

另外，至少在tfs 2005中的构建管理是有缺陷的，甚至与2008 slns相比也无法构建。我真的不喜欢我的源代码控制选择会影响我的部署选择，这就是为什么我的团队不是svn商店的原因。

回答

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

回答

我目前正在领导根据我当前使用的Rational Suite评估我的TFS。到目前为止，TFS 2008正在使用clearcase + clearquest。开发环境集成才是真正的亮点。

回答

对于我来说，这是两者之间最大的区别，并且我都使用了两者：

1)TFS与进行开发的" Visual Studio方式"紧密相关。这并不是说TFS与VS IDE紧密相连，这意味着TFS难以保持Visual SourceSafe的熟悉的"签入" /"签出"范例，即使实际上它不再是合适的模型也是如此。当开发人员可能会花时间与网络断开连接时，Subversion的"提交" /"更新"概念将更为现实。 TFS希望开发人员始终连接到服务器。那是一个很大的缺点。我个人认为，由于与Visual Studio的紧密集成，TFS在服务器和本地磁盘上文件的组织方式上不够透明。甚至TFS的更大支持者也承认，它的连接的签入/签出模型对于不工作的开发人员来说不是一个令人信服的选择。在人们开始关注SVN上的git和Mercurial等DVCS选项的情况下，TFS的"签出"模型似乎有点像恐龙。

2)费用。那些说TFS并不昂贵的人可能是很小的商店，或者不符合TFS的许可条款。我们需要做的所有事情都需要获得客户端访问许可证。我们是只负责管理错误的经理吗？我们需要约250美元的CAL(零售TFS许可证中包含5个)。只是想报告问题的业务用户？ 250美元的CAL。开发人员？ 250美元(除非他们拥有MSDN，否则包含在其中)。服务器？ 500美元(如果我们有MSDN，则包括在内)。当然，向我们出售TFS副本的人会告诉我们，其他用户可以免费使用工作项目跟踪，但是这些其他用户只能看到他们自己创建的工作项目，而不能看到整个团队的工作项目，而这并不是在面向团队的敏捷环境中太有用了。当我们拥有一个中型组织时，所有这些加在一起，而当许多同类最佳的产品(如SVN和CruiseControl.net)的增量成本为$ 0时，就很难证明这一点。 (不过，为了公平起见，我仍在等待一个非常好的OSS问题跟踪器)

3)项目结构。在项目数量较少的大型团队中，TFS可能会运作良好。如果我们内部有许多小型的，未连接的或者松散连接的业务线应用程序，则TFS的结构可能开始变得霸道。一方面，无法定义项目本身的分类法-我们可以在项目内设置"区域"，但是所有问题和文档都在"项目"的基本上下文中一起跟踪。创建新的"项目"通常很耗时，并且对于小小的努力来说是多余的。当然，SVN没有任何种类，因为它仅专注于源代码控制，但是如果我们需要良好的小项目灵活性，则SVN和其他问题跟踪工具可能是更好的选择。

我认为，这是值得的：

• 对于拥有大型，预算合理项目的大型团队，在Microsoft商店中，开发人员几乎只能在IDE中工作，因此TFS是赢家。当我们需要在项目中集中执行策略时，TFS也会胜出。
• 对于许多小型团队而言，其中有许多不同的小型项目，或者是成本问题所在的商店，或者团队的开发人员无法进行源代码控制，请选择SVN。

回答

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

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

尽管TFS支持合并，但它实际上是一个签入/签出系统。如果我们编辑文件，通常会发现该文件已被其他开发人员锁定。有很多解决方法，但是系统太复杂了，我们总是会遇到问题。例如，我们的开发人员发现，通过签出整个解决方案可以解决所有在NTFS中被设置为只读的文件的问题，该解决方案对所有文件设置了排他锁。我这样做了几次，因为subversion的结帐语法相同，而后者没有获得锁。

最终，Team Explorer(客户端)的容量高达400 MB，TFS服务器需要SharePoint和两天的安装时间。 Subversion一键式安装程序大约需要30 MB，它将在一分钟内为我们安装服务器。 TFS具有许多功能，但是其基础是如此不稳定，我们将永远不会使用或者关心它们。 TFS就许可证而言是昂贵的，并且随着时间的推移，开发人员将浪费大量的时间在堆栈溢出上，而不是编写代码：P

回答

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

• Bugzilla用于问题跟踪
• Apache Subversion作为源代码存储库后端
• VisualSVN服务器，用于管理服务器上的SVN
• 客户端上的TortoiseSVN(在Windows资源管理器中)和AhnkSVN或者VisualSVN(在Visual Studio中)
• CruiseControl.NET用于自动构建

费用：0美元
好处：无价

如果团队很小，或者不准备接受谁的TFS流程，那么SVN和开源工具是最佳选择。

回答

我认为这取决于完成项目的情况和环境。如果我们只有一个简单的小项目，那么SVN很棒。正如一些人已经写道，VisualSVN可以很好地集成到Visual Studio s.t中。我们不必通过本机文件系统进行签入/签出。

TFS非常适合版本控制，但如果我们真正使用它的所有功能，则更好。在我眼中，如果我们将工作项用作集成的存储库来处理客户错误报告，新功能请求以及通过管理任务以及根据估计的时间，已用时间和剩余时间来跟踪项目的进度，这真的很有价值适应症。
真正有趣的是使用将工作项与源代码签入关联的功能。有关更多信息，请参见此处。

回答

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

内置的用户界面非常有用，但是也存在缺陷。如果我从解决方案资源管理器中签出，则有时未签出已添加的文件。如果从"团队源代码管理"窗口中执行此操作，则它会完美运行。这是为什么？我很期待VS2010中的TFS，因为我听说过很多很棒的东西，而SVN远非完美，但我希望其中的某些功能能更直观地发挥作用。

亚当

回答

我们是从SVN到TFS2010迁移过程中的一个小团队。我们这样做的最大理由是将Visual Studio和WebAccess集成在一起以进行错误跟踪，这已成为TFS的一部分。

@亚当：希望我们会有更好的体验。不能告诉...

回答

我的10美分：

TFS2005是一个难以安装甚至难以维护的玩笑
TFS2008稳定易安装，易于维护，并且可以自动运行。
TFS2010是史诗级的！安装是狗essssyyyy。管理非常容易；这是一个布局精美的用户界面。将其与VS2008集成并不是一件容易的事，因为我们无法在vs2008中创建项目，而必须使用vs2010(这很愚蠢)。 TFS2010还允许我们更改共享点项目的位置，而不用拥有TFS2008那些糟糕的子文件夹。 TFS2010还具有诸如燃尽图之类的工具，对项目管理非常有用。就像TFS2010面向包括客户在内的整个生产团队一样！它仍然花费太多，尽管:(

回答

TFS一英里。

我因使用基于文件的SVN文件方法而无意中给自己带来了太多问题。
我曾遇到的源代码控制问题：
TFS 0问题超过2年
SVN丢失计数...

是的，我知道TFS的价格对于大多数公司来说都是因素，这真是太可惜了。如果拥有合理的定价模型，MS可能会拥有更多的市场份额(和利润)。

回答

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

入住/退房模式

这对于TFS源代码控制是一个巨大的弊端。不幸的是，即使我们不想这样做，VS也会自动为我们签出项目。我一直处于有人签出一些文件然后去度假的情况。我负责重组目录结构，但无法完成，因为一堆文件已签出给该人。 GUI中无法撤消签出，这意味着必须在命令行中一一完成。否则，我必须弄清楚如何为此编写一个Power Shell脚本。

VS需要做所有事情

有时我想编辑一个文本文件并签入。这需要我启动VS 2010，这是一个巨大的野兽，只是编辑文件并签入。SVN花了几秒钟的时间现在花了我一分钟。

正如其他一些人指出的那样，如果未检出文件，则将文件标记为只读。如果使其可写并在VS之外进行编辑，TFS将无法识别。这使VS之外的编辑变得烦人。这意味着，启动VS，签出文件，用另一个编辑器对其进行编辑，然后签入VS。

SVN中一些简单的操作现在很痛苦

• 也许我还没有弄清楚，但是我发现回滚变更集对于TFS来说非常繁琐。
• 将文件添加到源代码管理中(这不是解决方案的一部分)是一个巨大的难题。 TFS源代码管理资源管理器仅显示源代码管理中的哪些文件，而不显示哪些文件(可能不知道该设置在哪里)。使用Tortoise SVN，我只需在文件夹上按Commit，然后选择要添加的文件。