您将为1000多个开发者组织使用哪个版本控制系统?为什么?

时间:2008-09-15 18:32:50

标签: version-control dvcs

那里有很多SCM系统。有些开放,有些是封闭的,有些是免费的,有些是非常昂贵哪一个(请只选择一个)你会用于一个拥有多个网站的3000多个开发者组织(有些网站背后的链接非常慢)?解释为什么选择你选择的那个。 (给出一些理由,而不只是“因为”。)

33 个答案:

答案 0 :(得分:38)

答案 1 :(得分:21)

我曾在一些拥有1000多名员工的公司工作过,我发现他们都使用Perforce。

我问过“你为什么不用别的东西?SVN?Git?Mercurial?Darcs?” - 他们已经说过了(这对所有公司都是一样的) - 当他们做出决定时与Perforce一起,它或者是SourceSafe,还是CVS - 老实说,考虑到这三种选择,我也会选择Perforce。

“更难”的版本控制系统很难获得如此多人的关注,当你的大部分软件团队在彼此18英尺范围内工作时,DCVS的许多好处都不那么有用。

Perforce有许多API钩子供开发人员使用,而对于集中式系统,它有很多chutzpah。

我并不是说这是最好的解决方案 - 但我至少看过Perforce工作的一些非常大的公司,而且几乎无处不在。

答案 2 :(得分:10)

Git是为Linux内核编写的,这可能是您可以找到公共信息的最接近的例子。

答案 3 :(得分:5)

我想说git,但不要认为那个规模的公司会成为所有Linux(Windows对git的支持仍然很糟糕)。因此,请使用Linux之前使用的SCM,即BitKeeper

答案 4 :(得分:5)

截至2015年,最重要的因素是使用分布式版本控制系统(DVCS)。使用DVCS的主要好处是:通过减少源代码操作的摩擦,允许在多个级别进行源代码协作。这对于1000多个开发者组织来说尤其重要。

减少摩擦

单个开发人员签到与协作活动分离。轻量级登记表可以在短时间内(每小时或每天多次登记)鼓励清洁单位的独立工作。随着系统在分布式组织中建立,协作自然会以不同的,通常更长的时间尺度(每天,每周,每月与其他人同步)进行处理。

使用Git

在DVCS选项中,您可能只使用Git 并利用GitHubBitbucket上的优秀社区。对于大型私人组织,内部社区内部源代码托管可能很重要(有供应商销售私人托管系统,如Atlassian Stash,可能还有其他人。)< / p>

使用Git的主要原因是它是最受欢迎的DVCS。因此:

  • Git已广泛集成到各种开发工具链中

  • 大多数开发人员都知道并使用Gi​​t

  • Git是well-documented

或Mercurial

作为Git的替代品,Mercurial也非常好。 Mercurial比Git具有更清晰,更正交的命令集。在2000年代后期,它曾经比Windows系统上的Git更好地支持,这主要是因为核心开发人员更关心Windows。

GUI

对于那些想在命令行中使用GUI而不是githg的人来说,SourceTree是一个很棒的Windows和OS X应用程序,它为两者提供了一个干净的界面Git和Mercurial。

过时的建议

截至2010年,我向Mercurial推荐TortoiseHG。它是Windows支持和分布式版本控制功能的最佳组合。

从2006年到2009年,我推荐Subversion(SVN),因为它是免费的,并且与大多数IDE有很好的集成。对于组织中旅行或喜欢更分散的模型的人来说,他们可以使用Git进行所有本地工作,但是当他们想要共享代码时仍然会提交到SVN存储库。这是集中式和分布式系统之间的重要平衡。请参阅Git-SVN Crash Course开始使用。使用SVN的最后也许是最重要的原因是TortoiseSVN,这是一个用于SVN的Windows客户端,可以让任何人右键单击访问存储库。在我的公司,这已被证明是向非开发人员提供存储库访问权限的好方法。

答案 5 :(得分:3)

任何DVCS(BitKeeper,git,Bazaar,Mercurial等)因为分发将减少中央“规范”SCM服务器的负载。需要注意的是,它们是相当新的技术,没有多少人熟悉它们的使用。

如果您想坚持使用较旧的集中式模型,我建议Perforce,如果您能负担得起,或者如果您不想为Perforce付费,则推荐Subversion。我推荐对CVS进行颠覆,因为它有足够的功能使它值得,但足够相似,已经知道CVS的开发人员仍然会感到舒服。

答案 6 :(得分:3)

答案 7 :(得分:3)

首先,CVS上的大NO。在2008年使用CVS就像驾驶92 Isuzu Trooper一样。他们在路上的唯一原因是人们花钱来维持他们,这纯粹是出于感情上的原因。 CVS是技术方面的老帽子,你会后悔的。

我通常也会远离公司规模的开源工具。 Subversion是一个非常棒的小工具,并且非常可靠,但是如果你失败或遇到一个你不知道的错误,那么你有责任修复它,而有3000人闲置。从这个角度来看,Perforce很便宜,我强烈推荐它。

令我惊讶的是,有多少人认为SCM专业人士会选择“免费”。从表面上看,管理起来看起来很棒但是当你在枪口下时,有一个高质量的支持团队在你身边。当你在周日凌晨3点醒来因为你在新加坡的团队无法做任何工作时,你不会认为“免费”是一个好主意。

源控制工具是关键任务,您可以谈论公司资产和知识产权。永远不要吝啬源控制工具!

答案 8 :(得分:2)

好的,直接免责声明:我是一家名为MKS的公司的开发人员,该公司为“企业”公司制作版本控制系统,作为名为Integrity的软件配置管理平台的一部分。 Blah blah blah,明显插头。

所以我不能老实回答这个问题。

但是,我想指出,人们建议分布式版本控制缺少对大公司来说非常重要的东西。对于他们来说,开发人员在处理版本控制系统时所具有的灵活性与他们对每批代码的绝对控制权相比并不重要。监管一致性和审计是一个比合并痛苦更重要的方式。

一家拥有1000多名开发人员的公司希望知道每个人都在做他们应该做的事情,并且没有人做他们不应该做的事情,所有事情都被跟踪,管理人员可以获得可以粘贴的可爱报告和图表进入他们的经理的PowerPoint幻灯片。

如果一家大公司并不特别关心这些事情,那么他们就更有可能让个别开发团队找出自己的东西,在这种情况下,1000多名开发人员正在使用大杂烩基于当时最方便的任何工具。

答案 9 :(得分:2)

不要使用CVS !!如果你想要CVS模型,Subversion是一个更好的选择。

答案 10 :(得分:1)

我很震惊,这里提倡DCVS-es的大多数人都被当作某种粉丝。 DCVS-es被渲染为另一个流行词,就像云计算,社交媒体等一样。

这里的一些人主张使用SVN以及一些特定的硬件设置,特定的磁盘存储应该(甚至能够)为表提供可靠性。现在不只是打败SCM的两个主要目的之一 - 即确保数据完整性?

您没有足够的数据存储级别信息来确保整个源代码库在所有过去的修订版中的完整性。如果您希望将数据迁移到另一台计算机上,该怎么办?如果你想逐步迁移它而不停止所有开发直到完成它会怎么样?如果出现安全问题并且有人与您的主副本混淆怎么办?你怎么找到最后一个有效的?存储完整性只能让您获得目标,并且无法解决任何问题。这正是因为它在不适当的抽象层次上运作。不是你关心的存储空间。这是你的代码库。

另一个问题。有些人无法相信3000多人实际上可以在同一个项目中运作。他们说“去烤自己的scm”,我想这是另一种表达方式“是的......对...... 3000+开发者......祝你好运”。与此同时,有些项目涉及更多人。从工程到法律,几乎可以做任何事情。但不知何故,当谈到软件开发时,它是不可能的,它不可能。这个想法(我想象)是这样的:什么? 3000多人触摸同一个文件?现在,那不可能。而且,是的,这是正确的。它不可能。问题是为什么你会让3000多人触摸同一个文件?在大自然中你会发现这种情况吗? 3000多名律师互相发送一份文件,直到最终达成一致意见为止?人们不会那样工作。这样的现实永远不可能。然而,理论上集中式CVS使其成为可能。更糟糕的是,它迫使人们实际与他们甚至不知道的人协调工作。在这种情况下,这甚至都不是让聪明人在船上的问题,尽管在我想象的数千人中很难保证他们每个人都不是白痴。这只是制造常见的愚蠢错误。每个人都犯了错误(字面意思)。为什么你突然想通知整个公司呢?

现在有些人可能会说 - 但你不必给每个人提供访问权限。嗯 - 这是作弊。这是在集中式环境中构建分布式工作流的绝望尝试。突然间你有一个两级树 - 具有提交权限的人发送所有那些没有的人。好吧,如果你走得那么远,为什么不同意不可避免的事情 - 没有也永远不会只是整个源代码库的单一通用版本。人们需要在他们独立的环境中工作,而这些环境很容易合并在一起。

这些天有很多DCVS。只有Git有这种跟踪内容而不是单个文件的方法,在这种情况下可能不是最佳选择(但这在很大程度上取决于项目的组织)。还有Mercurial,还有Bazaar。所以这两个属性并不相互依赖。

我真的不想在那里推荐任何具体的DCVS,我觉得不合适。然而,在大多数推荐的解决方案未分发的情况下,不确保数据完整性,实际上比没有任何CVS更糟糕,我觉得我需要写一些东西。问题应该是哪个DCVS最适合做这项工作。

答案 11 :(得分:1)

我怀疑您的组织中是否有3000名开发人员都使用相同的代码库。我在一家大中型软件公司工作,我们整个公司可能没有那么多,但也有很多独立的项目。

在内部,一些团体向其他团体提供在其产品中使用的版本;这不是通过SCM系统管理的。

我们自己的小组有自己的SCM,但只有大约25个活跃的开发人员。我们使用CVS,并且说实话它并不是真的取决于它(我们迁移但是有很多脚本/提交钩子和其他需要大量工作来改变的位和部分)。在合理大小的代码库上使用CVS的问题是许多操作非常慢并且涉及锁定其他开发人员。

答案 12 :(得分:1)

我会使用AccuRev。我使用过svn,cvs,clearcase(base,ucm),ccc / harvest,但没有一个能胜过AccuRev的优势。 “拥有多个网站的3000+开发者组织”?您可以使用Accurev分布式解决方案(AccuReplica) - 这意味着您只需要一台主服务器,并且您可以在远程站点上使用多个副本(因此具有“慢速链接”的那些将不会受到太大影响)

首先,AccuRev带来了一种独特的方法 - 基于流的SCM工具的真正新概念/设计/实现。不是以(坏)方式ClearCase-UCM这样做(因为ClearCase“stream”最终是分支),但是以现代方式滑动。

最好的是自己尝试一下,我知道他们提供了30天的试用版,并且有足够的许可证来玩这个工具 - 尝试它,你不会想要考虑其他工具。我的承诺。

答案 13 :(得分:1)

如果您有1000多名开发人员在使用单个软件,那么您就有资源投入大量自己的工具。无论你选择什么,你可能会做很多工作来适应你的情况。

微软的Team Foundation Server在微软的一些非常大的团队中使用,而TFS团队正在努力使其扩展得很好。此外,源控制和集成的整合错误跟踪很有吸引力。这并不便宜,而且管理足够麻烦,它不能很好地扩展到小团队,但对于你的情况,你可以承担这些费用。您可能还希望能够在遇到麻烦时调用像Microsoft这样的大型支持组织(但如果您使用免费软件,那么您可以选择在内部进行支持)。

如果贵公司有1000多名工程师,但他们正在处理单独发布的软件,我想您希望将每个工程师放在自己的服务器上。这使得性能更好,以及管理。但是,我坚持只使用一种源控制技术。

答案 14 :(得分:1)

我会用bitkeeper。我已经使用了bitkeeper,clearcase,accurev,perforce,subversion,cvs,sccs和rcs,而且所有这些bitkeeper都是最好的。我玩过git并且对它的速度印象深刻,但我认为它的UI有点麻烦(虽然这个意见是在仅使用它几天半之后形成的)。

bitkeeper具有相当笨重的GUI,但它们非常实用。 bitkeeper命令行工具可以说是最佳的,它的合并功能绝对是非常棒的。

我最喜欢的bitkeeper(这可能适用于所有分布式系统)是分支机构很便宜。创建分支是一种生活方式而不是恐惧。

答案 15 :(得分:1)

我会使用任何没有悲观锁定(http://old.davidtanzer.net/?q=node/118)机制的SCM。特别是因为您希望人们能够在任何相当大的项目中同时“编辑”同一个文件。

我个人会选择SVN和一些解决方案进行分发,但是因为在SVN中你只提交你改变的内容(无论如何每次提交应该都很少),网络开销非常小。此外,服务器负载可以通过更多硬件来处理。使用SVN时,我还没有找到硬件缩放的上限。

其他选择可能包括Linux内核人员使用的“git”,但我对此没有任何经验。

答案 16 :(得分:1)

如果你有这样一个庞大的组织,那么就不要强制要求一个特定的SCM。

我相信他们并非都在使用相同的代码,因此让团队自己选择最适合他们的东西是值得的。

(您可能需要提供一些培训,以便了解如何在Git,SVN和一些内部遗留系统之间进行选择。)

答案 17 :(得分:1)

Perforce的

我喜欢perforce所说的与CVS相比,分支机构管理必须更复杂(但仍然相当容易),并且您不需要错过中央官僚机构来创建分支机构/标签等。换句话说,它允许单个团队(或开发人员)在提交到由其他人集中管理的主线之前管理他们喜欢的源组件。

哦,我还说它有一个最好的GUI,同时还有一级公民命令行界面。我通常讨厌GUI,但他们的工作。

答案 18 :(得分:0)

Adob​​e使用Perforce

答案 19 :(得分:0)

如果你的意思是3000多名开发人员在相同的代码库上工作,我就不知道了。如果你的意思是在不同地点开展数百个项目并且你需要有一个标准,那么我会选择一些受到大量在线用户支持的热门话题,而不是那些让你在Google上获得10次点击的模糊内容。

就个人而言,我会选择SVN,我是一个拥有数百个开发人员的IT部门,而且有一个优秀的源控制应用程序就是SVN。

:)

// w ^

答案 20 :(得分:0)

我实际上会查看Team Foundation Server。这是一个非常好的系统,可以扩展,它可能很容易通过内部部门。我知道它是以Windows为中心的,但你也可以使用Linux / Mac的附加组件,你可以使用代理连接到一些连接速度慢的网站。

我会考虑在一个大型组织中拥有两个系统,它可能有助于在一些单独的案例中获得最佳效果。

答案 21 :(得分:0)

Perforce和TFS是我所知道的唯一选项。我知道它们都已经在微软的大型项目中使用过。 Vault 可能扩展得那么大,但我不知道它是否超过了500-1000个用户。

答案 22 :(得分:0)

事实证明Perforce可以在Google的单个服务器上扩展到5000多个用户,请参阅: Life on the Edge: Monitoring and Running a Very Large Perforce Installation

似乎许多最大的软件公司都将Perforce独占或作为主要的SCM使用。例如:Adobe,Cisco,SAP,Symantec,EA,UbiSoft和Autodesk都是Perforce用户。它并不完美但它仍然优于SVN或TFS(这两者本身都不好)

答案 23 :(得分:0)

Perforce也获得了我的投票。我没有在这么大的项目中使用它,但它在我的环境中绝对坚如磐石。它也有一个令人印象深刻的大项目简历。

[谣言]我听说过微软将它用于Vista。[/谣言]显然它是针对他们的定制版本,但它并没有比这更大。

答案 24 :(得分:0)

让我们看看选项。

1 - Perforce。被很多公司使用(正如人们所说)Adobe,亚马逊,MS,Google公司每天都在增长,发展并依赖于销售软件以便将食物放在桌面上,这是他们的选择。如果我需要一个支持多种网站的“全球解决方案”,我想这就是我要去的方式,等等对Win / Linux有好处(虽然不确定是Mac)

2 - SVN。大型团队也使用它,KDE使用它(巨大的,巨大的项目)目前在修订版880,000(是的!)非常适用于Windows和Linux使用(即使我在某些方面将TortoiseSVN称为低于平均水平)可以签订商业支持同样。适用于Windows / Linux / Macs。

3 - Accurev如果我试图成为“前卫”。如果没有一些测试并且首先习惯它,我就不会在整个公司上部署它。

4 - MS Team Foundation这可能是一个很好的解决方案,但我从未尝试过,可能只是Windows。

5 - Git / Bzr / Hg - Bzr和Hg有他们的“乌龟”所以,对Windows有好处(即使我不确定成熟度)Git暂时只会是linux,即使它是非常的好(比几年前更好更容易使用)。

我绝对不会,绝对没有JOSE使用Clearcase。期间浪费每个人的金钱,时间和理智。

避开:CVS / Clearcase /任何旧的

答案 25 :(得分:0)

Perforce是一个不错的系统,可以很好地扩展。

我在一个拥有约5000名员工的组织工作,而perforce就是 一个快速有效的系统。它结构良好,具有良好的分支支撑, 有原子提交。每个更改都有一个可以使用的更改编号 “软件考古学”和许多其他伟大的功能。

此外,它还支持windows,mac和unix,包括 良好的命令行,并有良好的脚本支持。

我之前使用过CVS,并且它不能很好地扩展到大于的组 大约25-50名工程师(主要是因为原子操作和性能)

答案 26 :(得分:-1)

我是Subversion粉丝,但有很多好的开源和封闭源选择。我会避免使用CVS,因为它实际上并不像现代SCM(没有原子提交等)。

有人可能会建议SourceSafe。像瘟疫一样避免它。 SourceSafe默默地摧毁历史,并且不会导致悲伤的结束。有点谷歌搜索会告诉你更多关于这一点。

Subversion已经成熟,拥有许多优秀的工具和IDE集成。它在大多数网络上运行良好,因为它使用HTTP来访问存储库。

几年前我参与过SCM转换,你能做的最好的事情就是尝试一下。 SCM供应商将为您的评估提供演示和技术支持。

选择SCM并非易事。这实际上取决于您的代码库和工作流程。有些系统比其他系统更好地处理巨大的代码库。有些处理分支并且合并比其他分支更好。有些比其他更好的远程访问。有些人拥有更细粒度的安全模型。

让所有与系统互动的人一起列出你需要/想要的东西。获取演示并将代码导入其中并进行试用。为一个大型集团选择SCM是一个重大项目,应该这样对待。

答案 27 :(得分:-1)

对于使用Visual Studio的开发人员,我强烈推荐使用TortiseSVN客户端和Visual-SVN附加组件的SVN。

答案 28 :(得分:-1)

如果他们都在使用相同的产品,可能是Perforce。

如果有很多较小的项目(2到50),我会运行几个Subversion(SVN)框。

答案 29 :(得分:-1)

我会使用Subversion。 Subversion已经在许多大型开发人员社区的大型分布式开源项目中得到了验证。此外,Subversion提交的事务性质使其非常适用于连接可能不可靠的情况。

答案 30 :(得分:-1)

Subversion易于扩展和拆分。 Perforce仅为少数员工花费数千美元,而且价格昂贵,此外,它没有提供任何颠覆所不能提供的东西。

Subversion非常简单,比cvs更好。

如果他们的Windows支持更好,我会推荐git

答案 31 :(得分:-1)

使用TortiseSVN(在Windows上)的SVN非常棒。我强烈推荐它。

答案 32 :(得分:-1)

在我们公司,我们使用alienbrain,但我们正在迁移到Perforce。 Perforce拥有您想要的一切:它包含代码和数据,他集成了用于持续集成的工具,它处理本地(每个开发人员)存储库,因此您可以在提交服务器之前在本地存储库中签入。

我投票支持Perforce