关于svn：TFS与开源替代品？

TFS vs open source alternatives?

我们目前正在为.NET开发设置源代码控制/构建/更多服务器，并且正在考虑利用Team Foundation Server(这花费很多钱)或组合多个开源选项，例如SourceForge Enterprise / GForge和Subversion以及CruiseControl.net等。有没有人走过OSS全面发展的道路，还是只有当您想要正确并尽快开始工作时才使用TFS？

我的工作目前使用的主要是OSS构建过程，并以Cruise Control作为引擎，这很棒。我建议，如果您不知道为什么需要TFS，则可能不值得花这笔钱。

关于OSS，您需要牢记的是，该软件要么已经被Java团队使用了多年，要么该软件是类似Java代码的移植。它坚固耐用，适用于特定目的。

Microsoft无法发布OSS代码，这就是为什么他们必须重新实现许多开放源代码的原因。因此，没有，这是没有必要的，并且该堆栈上已交付了数百万个项目。不利的一面是，TFS还具有很多不错的功能，而OSS堆栈则没有(轻松)提供这些功能，例如与bug /功能跟踪软件的集成。

我一直走OSS的方式，从来没有遇到过问题。我也强烈建议TeamCity用于您的CI解决方案。有一个免费许可证，我认为它使CC.NET脱颖而出，以便于配置和反馈。

我已经成为TFS的日常用户了大约1.5年。

源代码控制稳定
您不能轻易断开工作。文件检出将转到服务器。
自动合并的效果很好，但有时会破坏源文件(编码问题)。
TFS感觉迟钝！特别是测试经理。托管代码？
测试部分中存在各种愚蠢的错误，没有什么关键的。
测试运行开始(等待)的时间太长。
我偶尔会遇到SQL死锁！
问题跟踪很糟糕。您不得不在缓慢的集成对话框中工作，仅显示Web。我建议将其与其他问题跟踪系统(例如JIRA)进行比较
构建工作正常。

如果使用的是TFS，请确保安装VSTS2008SP1。我见过的绝大多数张贴投诉的人都在使用2005版。 2005年是经典的" Microsoft 1.0"综合症。后来的2个"版本"解决了很多问题。

2008年的Service Pack不仅是错误修复，而且还添加了许多新功能。

至于选择vs OSS，(这里和其他地方)有很多讨论。这不是一种便宜的产品-但这是许多情况下的最佳选择(其他情况下则是最糟糕的选择)。

我们查看了TFS，但最终选择了Subversion + Trac + VisualSVN。我们现在不执行CI，但我想我们将使用Cruisecontrol。

我开始在许多开源项目中使用Trac，这很棒。实际上，这只是TFS所做工作的一部分，因此您必须在那里做出决定-如果您使用所有内容，那么TFS可能会更好地将所有内容捆绑在一起。 Trac是Wiki /错误跟踪器/源浏览器。一切都是链接的-当您在提交消息中键入WikiPage的名称或说"修复bug＃1234"时，只要在Trac中看到该消息，链接就会转到正确的位置。它是可以帮助您完成工作的工具，但通常不会出现问题。

VisualSVN是TortoiseSVN(Subversion客户端)与VisualStudio之间的桥梁，极大地提高了生产率。他们有免费试用版，之后价格也不是很昂贵(每位用户50美元)，但值得。

Trac的一个可能缺点是在Windows世界中，要在IIS上工作是很痛苦的。我已经安装了很多次Trac，但是试图使其正常运行很快就感到沮丧。我最终在不同的IP上安装了Apache(也可以使用不同的端口)，然后就无缝了。

除了我团队中只有一个人(有一点经验)之外，没有人曾经使用过颠覆。一对夫妇使用了VSS，仅此而已。每个人都很怀疑，但我会在几天之内说他们都是were依者。在充分学习了Trac并适应了一切(几天之后)之后，每个人都被完全售出并喜欢它。

我们公司成功使用CruiseControl / SVN / nAnt / JIRA组合。

与TFS达成交易的突破在于，仅对于大型公司而言，这是值得的。对于拥有30个或更少开发人员的小型公司而言，这将是非常昂贵的，而这些公司已经从上述开源组合中受益匪浅。

Subversion + Cruisecontol.Net是一个很好的选择。
SVN功能丰富，稳定且灵活。

我只是直到最近才开始每天使用TFS，并且来自以前的开源堆栈，我发现它相当缺乏。

虽然所有错误和任务跟踪的集成都是一个很棒的功能，但负面因素使它更为重要。

我个人使用以下堆栈，该堆栈为我提供了从持续集成到企业规模的自动化部署所需的一切工作，而费用却很少：

颠覆
哈德森
nCover
nDepend
四面
吉拉
Jira和Subversion整合

与单独的OS工具集相比，使用TFS的真正好处是集成了各种可用信息流。

*创建需求并插入TFS
*创建一组将它们链接到需求的任务，并将它们分配给各个开发人员
*每个开发人员都在完成任务并签入，并将任务分配给签入的变更集
*引入了错误修复程序，在这种情况下，更改集将与错误修复程序请求相协调，您还可以将错误修复程序映射到原始需求

一旦完成此操作，所有信息就可以用于跟踪项目并评估工作，例如，错误修复引起的更改数量，产生更多错误或更改请求的要求等。

所有这些信息在中型和大型组织中都是非常有用的，从我现在所看到的情况来看，不可能(或者非常困难)跟踪集成不同的OS工具。

TFS堆栈不仅仅是源代码控制和CI /每晚构建设置。考虑一下项目管理，错误报告，所有这些不仅仅包括CruiseControl，SVN和NAnt。仅报告本身就值得投资。还要记住，如果您是MSDN订户/ ISV金牌合作伙伴/等。您可能会免费获得其中的一些...

我以为我会尝试一个新的视角，因为我还没有尝试过，但是我计划在即将到来的项目中使用Bitten for CI。它在Trac + SVN之上运行，这两个都是我成功用于许多项目的出色工具。

我认为TFS对于上面帖子中提到的所有其他功能都值得。尽管它的连续构建功能严重不足，所以我们使用了很棒的CruiseControl.NET来扩展该部分。如果我们现在就选择TFS，那么我们唯一选择的理由就是我们正在跨产品跨平台开发。因此，即使您已经考虑过这一点，也可以考虑使用OSS。 Subversion / Trac将是我最喜欢的组合，因为CruiseCOntrol.NET仍然是主力。使用mono的CC.NET在Linux和Mac上运行良好。

TFS2010具有TFS Basic，该软件不收费(不包括您的msdn订阅/ Visual Studio许可)。
每个VS许可证限制为1，但是对于非VS用户，您仅需要其他许可证

仅凭VS2010中的UI自动化，TFS就成为使开源解决方案齐备的赢家

我非常同意这样的观点，只有当您确切知道需要它时，才值得使用TFS。基于OSS的廉价或免费插件，如Visual SVN和TestDriven.Net是如此出色，以至于与VS的集成已经是无缝的。

我已经看到了两者的使用情况(尽管我是Java开发人员)。选择和混合方法的好处是，您可以为所有内容选择最好的位(例如，我会查看Hudson for CI-它对于Java十分出色，也适用于.Net，并且有大量的插件，使用起来真的很简单) )。缺点是您必须自己进行所有集成。但是，这在Java世界中变得越来越容易。另外，不要让人们告诉您受支持的产品更好。在此领域中的许多OSS产品上，质量都非常好，您可以从竞争中获得更好的支持，而不必等待供应商的支持合同中的答复(IBM，我正在寻找您)

希望这可以帮助。

值得一提的是，多种TFS功能的最佳替代方案不一定是OSS，而是低成本的商业软件，例如NDepend用于代码质量和体系结构探索，NCover用于代码覆盖，TestDriven.NET用于嵌套在IDE中进行测试...

我们在这里逐步建立了一个开发堆栈，目前正在使用：