svn - TFS 与开源替代方案？

Question

我们目前正在为 .NET 开发设置源代码控制/构建/和更多服务器，我们正在考虑使用 Team Foundation Server（花费大量资金）或结合几个开源选项，如 SourceForge Enterprise/GForge 和 Subversion 和 CruiseControl.net 等。有没有人走过完整的 OSS 道路，或者只有当你想把它做好并尽快开始工作时才使用 TFS？

score 5 · Accepted Answer

我的工作目前主要使用以巡航控制为引擎的 OSS 构建过程，它很棒。我建议，如果您不知道为什么需要 TFS，那么这可能不值得。

对于 OSS，您必须牢记的是，该软件要么已被 Java 团队使用多年，要么该软件是类似 Java 代码的移植。它坚固耐用，适合用途。

微软不能发布 OSS 代码，这就是为什么他们必须重新实现很多开源的东西。所以，不，没有必要，并且已经有数百万个项目在该堆栈上交付。另一方面，您可以通过 TFS 获得许多通过 OSS 堆栈无法（轻松）获得的不错的功能，例如与您的错误/功能跟踪软件的集成。

score 4 · Accepted Answer

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

score 3 · Accepted Answer

大约 1.5 年以来，我一直是 TFS 的日常用户。

源代码控制稳定
你不能轻易断网工作。文件签出到服务器。
自动合并效果很好，但有时它会损坏源文件（编码问题）。
TFS有一种呆滞的感觉！？尤其是测试经理。托管代码？
测试部分有各种愚蠢的错误，没什么关键的。
测试运行需要很长时间才能开始（待定）。
我偶尔会遇到 SQL 死锁！？
问题跟踪很烂恕我直言。您被迫在缓慢的集成对话框中工作，网页仅显示。我建议将其与其他问题跟踪系统（如JIRA ）进行比较
构建工作正常。

score 2 · Accepted Answer

如果您使用的是 TFS，请确保安装 VSTS2008SP1。我见过的绝大多数发布投诉的人都在使用 2005 版。2005年是典型的“微软1.0”综合症。后来的两个“版本”已经解决了很多问题。

2008 年的 Service Pack 不仅仅是一个错误修复 - 而是添加了许多新功能。

至于选择与 OSS - 有很多讨论（这里和其他地方）。它不是一个便宜的产品——但它是很多场景的最佳选择（对其他场景来说也是最糟糕的选择）。

score 2 · Accepted Answer

我们查看了 TFS，但最终选择了 Subversion + Trac + VisualSVN。我们现在不做 CI，但我认为 Cruisecontrol 将是我们会使用的。

我开始在许多开源项目中使用 Trac，它很棒。它实际上只是 TFS 功能的一部分，因此您必须在那里做出决定——如果您使用所有东西，TFS 可能会更好地将它们结合在一起。Trac 是一个 wiki/bug 跟踪器/源浏览器。一切都是链接的——当您输入 WikiPage 的名称或在提交消息中说“Fix bug #1234”时，只要您在 Trac 中看到该消息，链接就会转到正确的位置。它是一种工具，可以帮助您完成工作，但通常不会妨碍您。

VisualSVN 是 TortoiseSVN（一个 Subversion 客户端）和 VisualStudio 之间的桥梁，极大地提高了生产力。他们有一个免费试用版，之后它不是很贵（50 美元/用户），但非常值得。

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

除了我团队中的一个人（他有一点经验），以前没有人使用过颠覆。一对夫妇使用过 VSS，仅此而已。每个人都很怀疑，但我会说几天之内他们都皈依了。在完全学习了 Trac 并习惯了一切（再过几天）之后，每个人都完全被卖掉了并且喜欢它。

score 1 · Accepted Answer

我们公司使用 CruiseControl/SVN/nAnt/JIRA 组合取得了巨大成功。

TFS 的交易破坏者是它只对大公司值得。对于拥有 30 名或更少开发人员的小公司来说，这将是非常昂贵的，它们已经从上述开源组合中受益匪浅。

score 1 · Accepted Answer

1

Subversion + Cruisecontol.Net 是一个不错的选择。SVN 功能丰富、稳定且灵活。

于 2008-09-15T10:31:22.960 回答

score 1 · Accepted Answer

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

* 创建一个需求并插入到 TFS
* 创建一组将它们链接到需求的任务并将它们分配给各个开发人员
* 每个开发人员处理他的任务并签入，将任务分配给签入的变更集
* 一个错误修复进来，同样在这种情况下，更改集将与错误修复请求协调，您还可以将错误修复映射到原始需求

一旦完成，所有信息都可以用于跟踪项目并评估工作，例如一个 bug 修复导致了多少更改，即产生了更多 bug 或更改请求的需求等等。

所有这些信息在大中型组织中都非常有用，而且据我现在所见，不可能（或非常难以）跟踪集成不同的操作系统工具。

score 1 · Accepted Answer

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

score 1 · Accepted Answer

我最近才开始每天使用 TFS，并且来自以前的开源堆栈，我发现它非常缺乏。

虽然所有错误和任务跟踪的集成是一个非常棒的功能，但负面因素超过了它。

我个人使用以下堆栈，它为我提供了我们需要做的一切，从持续集成到企业规模的自动化部署，成本只是其中的一小部分：

score 0 · Accepted Answer

我已经看到了这两种情况（尽管我是一名 Java 开发人员）。选择和混合方法的好处是您可以为所有内容选择最好的位（例如，我会查看 Hudson 的 CI - 它非常适合 Java，也适用于 .Net，并且具有大量插件，并且使用起来非常简单）。缺点是您必须自己完成所有集成。然而，这在 Java 世界中变得容易多了。另外，不要让人们告诉您受支持的产品更好。在这个领域的许多 OSS 产品上，质量非常好，您可以从社区获得更好的支持，而不是等待供应商支持合同的答复（IBM，我在看你）

希望这可以帮助。

score 0 · Accepted Answer

我强烈同意只有在您确切知道自己需要什么的情况下才值得使用 TFS 的观点。Visual SVN 和 TestDriven.Net 等基于 OSS 的廉价或免费插件非常好，以至于与 VS 的集成已经是无缝的。

score 0 · Accepted Answer

我想我会提出一个新的观点，因为我还没有尝试过，但我计划在即将到来的项目中使用Bitten进行 CI。这在 Trac+SVN 上运行，这两个都是我成功用于许多项目的好工具。

score 0 · Accepted Answer

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

颠覆
巡航控制
RedMine（将错误跟踪与源代码控制集成在一起，包括 wiki、基本项目管理等）。

score 0 · Accepted Answer

我认为 TFS 对于上述帖子中提到的所有额外功能都是值得的。虽然它的连续构建功能严重缺乏，所以我们使用 CruiseControl.NET 来增强该部分，这很棒。如果我们现在就选择 TFS，我们选择反对 TFS 的唯一原因是我们正在转向跨平台开发我们的产品。因此，如果您甚至考虑过这一点，请考虑 OSS。Subversion/Trac 将是我最喜欢的组合，CruiseCONtrol.NET 仍然是主干。使用 mono 的 CC.NET 在 Linux 和 Mac 上运行良好。

score 0 · Accepted Answer

TFS2010 有一个 TFS Basic，它不需要任何费用（除了您的 msdn 订阅/visual studio 许可证之外）。每个 VS 许可证限制为 1 个，但您只需要为非 VS 用户提供额外的许可证

仅 VS2010 中的 UI 自动化就使 TFS 胜过拼凑开源解决方案

score 0 · Accepted Answer

值得一提的是，广泛的 TFS 功能的最佳替代品不一定是 OSS，而是低预算的商业，例如用于代码质量和架构探索的NDepend ，用于代码覆盖的NCover ，用于测试嵌套在 IDE 中的TestDriven.NET ……

svn - TFS 与开源替代方案？

17 回答 17

Related

Reference