那里有许多SCM系统。有的是开放式的，有的是封闭式的，有的是免费的，有的相当昂贵。对于拥有多个站点(某些站点背后的链接非常慢)的3000多个开发人员组织，我们将使用哪一个(请仅选择一个)？解释为什么我们选择了自己选择的一个。 (给出一些原因，而不仅仅是"因为"。)

解决方案

回答

3000多家开发人员组织？？？我会建立自己的。

回答

任何DVCS(BitKeeper，git，Bazaar，Mercurial等)都可以分发，因为它可以减少中央"规范" SCM服务器上的负载。需要注意的是，它们是相当新的技术，并且很少有人会熟悉它们的用法。

如果我们想使用较旧的集中式模型，如果可以承受，我建议使用Perforce，如果我们不想为Perforce付费，则建议使用Subversion。我建议使用CVS进行颠覆，因为它具有足够的功能使其值得使用，但又足够相似，以至于已经知道CVS的开发人员仍然会感到满意。

回答

Adobe使用Perforce

回答

Git是为Linux内核编写的，它可能是我们可以找到公共信息的最接近的例子。

回答

我想说git，但是不要以为有这么大规模的公司会全部使用Linux(Windows对git的支持仍然很糟糕)。因此，请继续使用Linux在git之前使用的SCM，即BitKeeper

回答

在几家拥有1000多名员工的公司工作过后，我发现他们大体上都使用Perforce。

我问"为什么不使用其他东西？SVN？Git？Mercurial？Darcs？"，当他们决定选择Perforce时，他们说过(对于所有公司都是一样的)，或者是SourceSafe，或者是CVS，说实话，考虑到这三个选择，我也会选择Perforce。

"更困难的"版本控制系统很难吸引这么多人，并且当大部分软件团队都在18英尺的范围内工作时，DCVS的许多好处就没有那么多了。

Perforce有很多API挂钩供开发人员使用，对于集中式系统，它有很多麻烦。

我并不是说这是最好的解决方案，但我至少已经看到Perforce工作的一些非常大的公司，而且足够好，它几乎无处不在。

回答

我将使用任何没有悲观锁定的SCM(http://old.davidtanzer.net/?q=node/118)机制。尤其是因为我们希望人们能够在任何大型项目中同时"编辑"同一文件。

我个人会选择SVN以及一些分发解决方案，但是由于在SVN中我们仅提交更改(无论如何每次提交都应该很少)，因此网络开销很小。同样，服务器负载可以用更多的硬件来处理。使用SVN时，我尚未找到硬件扩展的上限。

其他选择可能包括Linux内核人们使用的" git"，但我对此确实没有任何经验。

回答

如果我们拥有如此庞大的组织，则不要强制使用单个特定的SCM。

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

(我们可能需要提供一些培训，以便了解如何在Git，SVN和某些内部旧版系统之间进行选择。)

回答

Perforce

与CVS相比，我对perforce的看法是，分支机构的管理必须更加复杂(但仍相当容易)，并且我们无需打扰中央官僚机构来创建分支机构/标签等。换句话说，它允许单个团队(或者开发人员)按照自己的喜好来管理其源组件，然后再提交给由其他人集中管理的主线。

哦，我还要说的是，它具有最好的GUI之一，同时仍然具有一等公民命令行界面。我通常讨厌GUI，但是它们却可以工作。

回答

如果他们都在同一个产品上工作，可能是Perforce。

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

回答

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

我在大约5000名员工的组织中工作，而perforce是
快速高效的系统。它可以很好地扩展，具有良好的分支支持，
有原子提交。每个更改都有一个可以使用的更改编号
用于"软件考古学"和许多其他重要功能。

此外，它对Windows，Mac和Unix也有很好的支持，包括
良好的命令行，并具有良好的脚本支持。

我以前使用过CVS，但不能很好地扩展到大于
大约25-50名工程师(主要是由于原子操作和性能)

回答

截至2015年，最重要的因素是使用分布式版本控制系统(DVCS)。使用DVCS的主要好处是：通过减少源代码操纵的摩擦，可以在多个级别进行源代码协作。对于1000多个开发人员组织而言，这一点尤其重要。

减少摩擦

各个开发人员签入与协作活动脱钩。轻量级签入鼓励在短时间内进行整洁的独立工作(每小时或者每天多次签入)。当在分布式组织中建立系统时，自然会以不同的，通常更长的时间范围(与他人，每天，每周，每月同步)进行协作。

使用Git

在DVCS选项中，我们可能应该只使用Git并利用GitHub或者Bitbucket上的优秀社区。对于大型私人组织，内部社区和内部源代码托管可能很重要(有些供应商出售诸如Atlassian Stash等私有托管系统)。

使用Git的主要原因是它是最受欢迎的DVCS。因为这：

• Git已很好地集成到各种开发工具链中
• Git被大多数开发人员所熟知和使用
• Git有据可查

或者水银

作为Git的替代产品，Mercurial也非常出色。与Git相比，Mercurial的命令集稍微更简洁，更正交。在2000年代后期，在Windows系统上，它比Git受到更好的支持，主要是因为有核心开发人员更关心Windows。

图形用户界面

对于那些想在命令行上使用GUI而不是git和hg的人来说，SourceTree是一款出色的Windows和OS X应用程序，它为Git和Mercurial都提供了简洁的界面。

过时的建议

从2010年起，我推荐使用Mercurial与TortoiseHG。它是Windows支持和分布式版本控制功能的最佳组合。

从2006年至2009年，我建议使用Subversion(SVN)，因为它是免费的，并且与大多数IDE集成良好。对于组织中旅行或者更喜欢分布式模型的人员，他们可以使用Git进行其所有本地工作，但在希望共享代码时仍可以使用SVN存储库。这在集中式系统和分布式系统之间是一个很好的平衡。请参阅Git-SVN崩溃课程以开始使用。使用SVN的最后一个也是最重要的原因是TortoiseSVN，这是SVN的Windows客户端，任何人都可以通过鼠标右键单击来访问存储库。在我公司，这已被证明是一种向非开发人员提供存储库访问的好方法。

回答

不要使用CVS！如果需要CVS模型，则Subversion是更好的选择。

回答

如果我们是说3000多个开发人员在同一个代码库上工作，那我就不知道了。如果我们打算在不同地点从事数百个项目，并且需要一个标准，那么我会选择一些在大型在线用户支持下很受欢迎的工具，即不要让我们在Google上获得10次点击。

就我个人而言，我会选择SVN，我正在与数百名开发人员一起工作的IT部门中，并且首选的源代码控制应用程序是SVN。

:)

// W

回答

我会用位守护者。我曾经使用过bitkeeper，clearcase，accurev，perforce，subversion，cvs，sccs和rcs，在所有这些bitkeeper中，它们远非最好。我喜欢git，它的速度给我留下了深刻的印象，但是我认为它的UI有点笨拙(尽管这种意见是在使用了半天后才形成的)。

bitkeeper具有外观笨拙的GUI，但它们的功能异常出色。 bitkeeper命令行工具可以说是同类中最好的，并且其合并功能绝对出色。

我最喜欢bitkeeper(所有分布式系统都可能如此)的原因是分支的价格便宜。创建分支是一种生活方式，而不是令人恐惧的事情。

回答

Subversion易于扩展和拆分。
Perforce仅需几个员工就需要花费数千美元，这是昂贵的方法，此外，它还提供了Subversion无法提供的任何功能。

Subversion确实很容易，比cvs更好。

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

回答

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

我投票给Perforce

回答

首先，在CVS上大做文章。在2008年使用CVS就像驾驶一辆92 Isuzu Trooper。他们之所以上路，而人们花钱来维护它们，唯一的原因仅仅是出于情感上的原因。 CVS在技术上是老派，我们会后悔的。

通常，我也应该避开像公司这样规模的开源工具。 Subversion是一个出色的小工具，非常可靠，但是一旦我们掉下来或者遇到了自己不知道的错误，就有可能要修复它，而有3,000人处于闲置状态则有责任进行修复。从这种角度来看，Perforce便宜，我强烈推荐它。

令我感到惊讶的是，有多少人声称是SCM专业人士选择了"免费"。从表面上看，管理起来很不错，但是当我们精打细算时，这将有助于我们拥有一支高素质的支持团队。当我们由于新加坡团队无法完成任何工作而在周日的凌晨3点醒来时，我们不会认为"免费"是个好主意。

源代码控制工具是关键任务，我们在谈论公司资产和知识产权。永远不要无视源代码控制工具！

回答

如果我们有1000多个开发人员在开发单个软件，则我们有资源来投资自己的大量工具。无论我们选择什么，我们都可能会做大量的工作以使其适应情况。

Microsoft的Team Foundation Server已在一些大型团队中用于Microsoft，TFS团队正在努力使它很好地扩展。此外，源代码控制和错误跟踪的集成也很有吸引力。它并不便宜，而且管理很麻烦，无法很好地扩展到小型团队，但是对于情况，我们可以负担这些费用。当我们遇到麻烦时，我们可能还希望能够像Microsoft那样寻求大型支持组织的支持(但如果使用免费软件，则可以选择内部提供支持)。

如果公司中有1000多名工程师，但是他们正在开发单独提供的软件，那么我想我们希望将每个人都放在自己的服务器上。这使性能扩展和管理变得更好。但是，我坚持只使用一种技术进行源代码控制。

回答

我实际上会签出Team Foundation Server。这是一个很好的系统，可以扩展，通过内部IT部门可能很容易。我知道它是以Windows为中心的，但是我们也可以为Linux / Mac使用添加组件，并且可以为某些连接速度较慢的站点使用代理。

我会考虑在一个大型组织中拥有2个系统，这可能有助于在某些情况下获得最佳性能。

回答

我知道Perforce和TFS是唯一的选择。我知道它们都已在Microsoft的大型项目中使用。保管箱的规模可能会很大，但我不知道它是否会超过500-1000个用户。

回答

在Google的一台服务器上，Perforce被证明可扩展到5000多个用户，请参阅：
边缘生活：监视和运行非常大的Perforce安装

似乎许多最大的软件公司都单独使用Perforce或者将其用作主要的SCM。例如：Adobe，Cisco，SAP，Symantec，EA，UbiSoft和Autodesk都是Perforce用户。它不是完美的，但是仍然优于SVN或者TFS(两者都不是坏事)

回答

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

[谣言]我听说微软在Vista上使用了它。

回答

带有TortiseSVN的SVN(在Windows上)非常出色。我强烈推荐它。

回答

我是Subversion的粉丝，但是有很多不错的开放源代码和封闭源代码选择。我会避免使用CVS，因为它实际上不会像现代SCM那样堆叠(没有原子提交等)。

有人可能会建议SourceSafe。避免像瘟疫一样。 SourceSafe默默地破坏了历史，并没有带来悲伤。稍作谷歌搜索将告诉我们更多有关此的信息。

Subversion已经成熟，并且具有许多很好的工具和IDE集成。由于它使用HTTP访问存储库，因此它在大多数网络上均能很好地工作。

几年前，我从事SCM转换工作，我们能做的最好的事情就是尝试一下。 SCM供应商将为我们提供评估的演示和技术支持。

选择SCM并非易事。这实际上取决于代码库和工作流程。一些系统比其他系统处理更好的代码库。有些处理很多分支，然后合并得更好。有些比其他的更适合远程访问。有些具有更细粒度的安全模型。

让每个将与系统交互的人在一起，并列出我们需要/想要的东西。获取演示并将代码导入其中并进行尝试。为庞大的团队选择SCM是一项重大项目，应该这样对待。

回答

我会用Subversion。 Subversion已在具有大型开发人员社区的许多大型，分布式，开源项目中得到证明。同样，Subversion提交的事务性使其成为连接可能不可靠的情况的理想选择。

回答

• 对于如此庞大的安装，至少需要满足以下主要要求：数据安全性，成熟度，健壮性，可伸缩性，价格(无论每个席位的价格如何，每个席位许可证与开源代码的区别总是很大的)，易于管理
• 我认为颠覆就好了。
• 有可用的支持(来自collabnet，clearvision，wandisco等)。我们可以问他们颠覆是否能够处理任务。
• subversion有一个非常成熟的数据库后端-FSFS。它绝对坚如磐石，从1.5开始，它可以处理很多修订而不会降低性能。修订版本写在文件系统中。因此，Subversion存储库的可靠性取决于文件系统，操作系统和存储系统的质量。
• 这就是为什么我建议将ZFS作为文件系统的Solaris 10. ZFS对于生产系统确实具有出色的文件系统功能。但最重要的是，它提供了数据完整性校验和。因此，使用Subversion存储库中的大量源代码，我们将不必担心由于无提示的硬盘位错误或者控制器或者电缆位错误而导致存储库损坏。到目前为止，ZFS已经足够成熟，可以安全地用作UFS或者任何替代品。
• 我不知道硬件要求。也许Collabnet可以给我们建议。
• 但是，第二代重击器(即Sun Fire X4540服务器)是一个很好的开始(如果事实证明它太慢，则可以用作NFS存储或者备份存储-无论如何，我们肯定可以很好地利用它) ：我们可以拥有(全部都安装在漂亮的4U机架服务器中，价格为80.000 $(标价-这可能是可以协商的))：48 TB磁盘空间！，8个AMD Opteron CPU内核，64 GB RAM，预安装Solaris 10、3年白金Sun提供的软件和硬件支持。因此，该服务器的纯硬件和支持价格将是3000个开发人员每席位25美元。
• 为了确保真正的数据安全，我们可以按以下方式对48个硬盘进行分区：3个用于操作系统的驱动器(3路Raid-1镜像)，3个热备用(未使用，发生故障时处于备用状态)其他驱动器)，则为Subversion存储库提供14个3路Raid 1镜像(14 * 3 = 42个驱动器)的zfs池。如果我们只想填充14 TB ZFS Raid空间的80％，那么这大约是该存储库实际可用磁盘空间的10 TB，即每个开发人员平均3 GB。
• 使用以下配置：具有10 TiB 3-way Raid-1 ZFS冗余和校验和磁盘空间的Sun x4540 thumper上的Subversion 1.6，这应该是一个非常严肃的开始。
• 如果计算能力不足以容纳3000多名开发人员，那么我们可以购买功能更强大的服务器，它可以使用节拍器的磁盘空间。如果磁盘性能太慢，则可以将大量的快速scsi驱动器连接到计算服务器，然后使用节流器作为备份解决方案。
• 当然，从collabnet获得有关此Subversion服务器的规划和部署的咨询服务，并从sun获得对硬件和solaris操作系统的白金支持将是有意义的。
• 当地团队的成员可以快速获得结帐
• 它将大大减少the击器的负载-这意味着通过这种配置，我们完全不必担心the击器是否能够处理负载
• 它降低了带宽成本
• M3000服务器是Sparc64服务器，价格中等，具有高端RAS功能。大多数数据路径甚至cpu寄存器都经过校验和，等等。RAM不仅受ECC保护，而且具有与IBM Chipkill功能等效的功能：突袭内存：不仅检测到并纠正了单个位错误，而且整个内存芯片都可能发生故障完全没有数据丢失的情况-类似于RAID阵列中的硬盘故障。
• 由于ZFS文件系统会在数据到达CPU之前或者之后对数据进行基于CPU的错误校验和，因此J4500的存储控制器和电缆的质量并不重要。重要的是M3000 CPU，内存，内存控制器等的位错误预防和检测功能。
• 不幸的是，sun用于提高质量的高质量记忆棒的价格甚至更高，以至于四核(八线程)4GB Ram M3000 + 48 TB J4500的组合大致相当于to击器，但如果为了将服务器内存从4GB增加到8、16或者32 GB以用于内存中缓存，价格急剧上涨。但是，如果使用分布式团队的主从配置，那么4GB的配置甚至就足够了。
• 如果此3000开发人员存储库的源代码和数据完整性得到管理层的极高评价，那么这种硬件组合将是值得考虑的。然后，有必要添加两个或者多个节流器作为循环备份解决方案(不是必要的，以防止硬件故障，但可以防止管理员的错误或者在物理灾难时进行异地备份)。
• 由于这将是Sparc而不是x86解决方案，因此可以免费获得该平台的经过认证的Collabnet Subversion二进制文件。
• Subversion的优点之一还在于出色的文档：一本O'Reilly的优秀著作(带有Subversion的版本控制)也免费提供PDF或者HTML版本。
• 成熟-Subversion已被许多公司和开放源代码项目使用。
• 可伸缩性-使用主从复制，我们在主服务器上应该不会出现负载问题：签入的负载可以忽略不计。检出由从站处理。
• 连接慢的本地团队没有高延迟(由于复制)
• 低廉的价格：Subversion是免费的(每个席位免费)，出色的免费文档，在三年期间内，每个席位每年仅8 $的主服务器硬件和支持成本，用于奴隶的廉价linux盒，协作网等此外，由于主从复制，带宽成本较低。
• 易于管理：基本上无需管理主服务器：Subversion顾问可以部署所有内容。 Sun员工将更换有故障的硬盘驱动器等。从站可以是Linux机器，也可以是本地站点上可用的任何管理技能。出色的Subversion文档。

回答

我会使用AccuRev。我用过svn，cvs，clearcase(基准，ucm)，ccc / harvest，但是它们都无法击败AccuRev的优势。 "超过3000个具有多个站点的开发人员组织"？我们可以为此使用Accurev分布式解决方案(AccuReplica)，这意味着我们拥有一台主服务器，并且可以在远程站点上获得尽可能多的副本(因此，具有"慢速链接"的副本不会受到太大影响)

首先，AccuRev带来了一种独特的方法，即基于流的SCM工具的真正新概念/设计/实现。不是用(坏的)ClearCase-UCM方式(因为ClearCase的"流"最终是分支)这样做的，而是用光滑的现代方式。

最好是自己尝试一下，我知道他们提供30天的试用期，并具有足够的许可权来使用该工具进行尝试，并且我们不想考虑使用其他工具。我的诺言

回答

对于使用Visual Studio的开发人员，我强烈建议将SVN与TortiseSVN客户端和Visual-SVN添加组件一起使用。

回答

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

在内部，某些小组向其他小组分发发行版以在其产品中使用；这不是通过SCM系统进行管理的。

我们自己的小组有自己的SCM，但只有大约25个活跃的开发人员。我们使用CVS，说实话，它并不是完全适合它(我们已经迁移了，但是有很多脚本/提交钩子以及其他需要大量工作才能更改的点滴)。在合理大小的代码库上使用CVS的问题在于，许多操作非常缓慢，并且涉及将其他开发人员拒之门外。

回答

好的，完全免责声明：我是一家名为MKS的公司的开发人员，该公司为"企业"公司制作一个版本控制系统，作为名为Integrity的软件配置管理平台的一部分。等等等等，很明显。

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

但是，我想指出的是，有人建议使用分布式版本控制，这对于大型公司而言缺少重要的意义。对于他们而言，开发人员在处理其版本控制系统时拥有多少灵活性并不重要，要掌握对发布的每一行代码都具有绝对控制权，这对他们来说并不重要。监管合规性和审计是比痛苦的合并更重要的方式。

一家拥有1000多名开发人员的公司希望知道每个人都在做他们应该做的事情，没有人在做他们不应该做的事情，所有事情都得到了跟踪，经理们得到了可以粘贴到PowerPoint幻灯片中的漂亮报告和图形。为他们的经理。

如果一家大型公司并不特别在意这些事情，那么他们更有可能将其留给各个开发团队来确定自己的事情，在这种情况下，有1000多个开发人员正在使用各种各样的工具根据当时似乎最方便的方式进行。

回答

让我们看看这些选项。

1 Perforce。许多公司(如人们所说的那样)都在使用Adobe，Amazon，MS，Google等公司，这些公司不断成长，发展并依靠每天销售软件来将食物摆在桌面上，这就是他们的选择。我想如果我需要针对众多站点的受支持的"全局解决方案"等，那将是我的选择，这对Win / Linux有利(尽管不确定Macs)

2个SVN。大型团队也使用过KDE，它目前使用的版本(庞大，庞大的项目)的版本为880,000(是的！)对于Windows和Linux的使用都非常实用(即使我在某些方面称TortoiseSVN低于平均值)也可以与商业支持签订合同也一样同样适用于Windows / Linux / Mac。

3 Accurev如果我想变得"前卫"。如果不先进行测试并习惯它，我就不会在整个公司中部署它。

4 MS Team Foundation这可能是一个很好的解决方案，但我从未尝试过，并且可能仅适用于Windows。

5 Git / Bzr / Hg Bzr和Hg有其"乌龟"特性，因此对Windows有利(即使我不确定其成熟程度)Git暂时仅是linux，即使它非常好(而且更好)并且比几年前更易于使用)。

我永远也永远不会使用Clearcase。时期这是浪费每个人的金钱，时间和理智。

避免使用：CVS / Clearcase /任何较旧的版本