那里有许多 SCM 系统。一些开放的，一些封闭的，一些免费的，一些相当昂贵的。对于拥有 3000 多名开发人员且拥有多个站点（一些位于非常慢的链接后面）的组织，您会使用哪一个（请仅选择一个）？解释你为什么选择你选择的那个。（给出一些理由，而不仅仅是“因为”。）
Vasco Duarte
问问题
4183 次
33 回答
38
- 对于如此庞大的安装，至少有以下几个主要要求：数据安全性、成熟度、健壮性、可扩展性、价格（无论每个席位的价格如何，每个席位许可证与开源总是会产生巨大差异）、易于管理
- 我认为颠覆会很好。
- 有可用的支持（来自collabnet、clearvision、wandisco等）。你可以问他们颠覆是否能够处理你的任务。
- subversion 有一个非常成熟的数据库后端——FSFS。它绝对坚如磐石，从 1.5 版本开始，它可以处理很多版本而不会降低性能。修订被写入文件系统。因此，您的 subversion 存储库的可靠性取决于您的文件系统、操作系统和存储系统的质量。
- 这就是为什么我会推荐使用 ZFS作为文件系统的Solaris 10 。ZFS 为生产系统提供了非常棒的文件系统功能。但最重要的是，它提供了数据完整性校验和。因此，使用 subversion 存储库中的大量源代码，您不必担心存储库损坏，因为无声硬盘驱动器位错误或控制器或电缆位错误。到目前为止，ZFS 已经足够成熟，可以安全地用作 UFS 或任何替代品。
- 我不知道硬件要求。也许 Collabnet 可以给你建议。
- 但是一个非常好的开始（如果结果太慢，可以用作 NFS 存储或备份存储 - 你肯定可以很好地利用它）将是第二代重击器，即Sun Fire X4540 服务器：您可以拥有（所有都在一个不错的 4U 机架服务器中，价格为 80.000 美元（标价 - 这可能可以协商））：48 TB 磁盘空间！，8 个 AMD Opteron CPU 内核，64 GB RAM，预装 Solaris 10，3 年白金来自 sun 的软件和硬件支持。因此，仅此服务器的硬件和支持价格将是 3000 名开发人员的每个席位 25 美元。
- 为了确保真正的数据安全，您可以将 48 个硬盘驱动器分区如下：3 个用于操作系统的驱动器（3 路 Raid-1 镜像）、3 个热备件（未使用，在发生故障时备用其他驱动器），一个包含 14 个 3-way Raid 1 镜像（14*3=42 个驱动器）的 zfs 池，用于 subversion 存储库。如果您只想将 14 TB ZFS Raid 空间填充 80%，那么这将是存储库的大约 10 Tebibyte 实际可用磁盘空间，即每个开发人员平均 3 GB。
- 使用此配置： Sun x4540 thumper 上的 Subversion 1.6 具有 10 TiB 3-way Raid-1 ZFS 冗余和校验和磁盘空间，这应该是一个非常严肃的开始。
- 如果计算能力不足以满足 3000 多名开发人员的需求，那么您可以购买更强大的服务器来使用 thumper 的磁盘空间。如果磁盘性能太慢，您可以将大量快速 scsi 驱动器连接到计算服务器，并使用 thumper 作为备份解决方案。
- 当然，从 collabnet 获得有关该颠覆服务器的规划和部署的咨询服务以及从 sun 获得硬件和 solaris 操作系统的白金支持是有意义的。
- 编辑（对评论 #1 的回答）：对于分布式团队，可以进行主从配置：WebDAV-Proxy. 每个本地团队都有一个从服务器，用于复制存储库。开发人员从这个奴隶那里得到所有的结帐。签入从从属透明地转发到主控。这样，主站始终是最新的。绝大多数流量是结帐：每个开发人员都会收到任何开发人员提交的每个签入。所以结账流量应该是 3000 名开发者流量的 99.97%。如果您有一个拥有 50 名开发人员的本地团队，结帐流量将减少 98%。签入应该不是问题：任何人输入新代码的速度有多快？显然，对于一个小团队，你不会买一个重击器。您只需要一个有足够硬盘空间的盒子（即，如果您打算容纳 10TB 的空穴存储库）。它可以是 raid5 配置，因为数据丢失不是公司的末日。您也不需要 Solaris。如果当地人更喜欢它，你可以在上面安装 linux。再一次：询问像 collabnet 这样的顾问，这是否真的是一个合理的概念。有这么多座位，支付一次性咨询费用应该不是问题。他们可以设置整个事情。Sun 提供预装了 solaris 的盒子。你有太阳支持。因此，您不需要在现场安装 solaris 专家，因为配置在未来几年内不会发生变化。这种配置意味着 现场不需要solaris guru，因为配置在未来几年内不会改变。这种配置意味着 现场不需要solaris guru，因为配置在未来几年内不会改变。这种配置意味着
- 从团队到总部的慢线不会被多余的结账数据堵塞，
- 当地团队的成员可以快速结账
- 它将显着减少重击器的负载 - 这意味着使用该配置您根本不必担心重击器是否能够处理负载
- 它降低了带宽成本
- 编辑（在 M3000 发布之后）：一个更加极端的硬件配置甚至更加针对疯狂的数据完整性，这将是M3000服务器和J4500阵列的组合：
- J4500 存储阵列实际上是一个重击器，但没有 CPU 电源和外部存储接口，使其能够连接到服务器。
- M3000 服务器是一款 Sparc64 服务器，价格适中，具有高端 RAS 功能。大多数数据路径甚至 cpu 寄存器都经过校验和等。RAM 不仅受 ECC 保护，而且具有与 IBM Chipkill 功能相当的功能：它是对内存的突袭：不仅检测和纠正单个位错误，而且整个内存芯片都可能出现故障完全没有数据丢失 - 类似于 RAID 阵列中的硬盘驱动器故障。
- 由于 ZFS 文件系统在数据来自之前或之后对数据进行基于 CPU 的错误校验和，因此存储控制器的质量和 J4500 的布线并不重要。重要的是 M3000 CPU、内存、内存控制器等的比特错误预防和检测能力。
- 不幸的是，sun 用来提高质量的高品质记忆棒更加昂贵，以至于四核（八线程）4GB Ram M3000 + 48 TB J4500 的组合大致相当于重击器，但如果你愿意喜欢将服务器内存从 4GB 增加到 8、16 或 32 GB 用于内存缓存目的，价格急剧上涨。但是如果使用分布式团队的主从配置，也许 4GB 的配置就足够了。
- 如果管理层非常重视这 3000 名开发人员存储库的源代码和数据完整性，那么这种硬件组合将值得考虑。然后，添加两个或更多重击器作为轮换备份解决方案也是有意义的（不必防止硬件故障，但可以防止管理员错误或在物理灾难的情况下进行异地备份）。
- 由于这将是 Sparc 而不是 x86 解决方案，因此可以免费获得该平台的经过认证的Collabnet Subversion 二进制文件。
- subversion 的优点之一也是优秀的文档：O'Reilly有一本优秀的书（带有 Subversion 的版本控制）也可以免费提供PDF或HTML版本。
- 总结一下：Subversion 1.6 + Solaris 10 + 3-way-raid-1 冗余和校验和 ZFS + thumper + 本地团队的主从服务器复制 + sun 支持 + collabnet/clearvision/orcaware/Karl Vogel 咨询 +为所有开发人员提供的优秀且免费的颠覆手册，您应该有一个提供的解决方案
- 极高的数据安全性（对于如此多的源代码非常重要 - 您不想损坏存储库，确实会发生位错误，硬盘驱动器会发生故障！）您拥有一个真正可靠地保存所有版本/修订的主数据存储库：源代码控制系统的主要特点。
- 成熟度- Subversion 已被许多公司和开源项目使用。
- 可扩展性- 使用主从复制，您应该不会在主服务器上遇到负载问题：签入的负载可以忽略不计。结帐由奴隶处理。
- 慢速连接后的本地团队没有高延迟（因为复制）
- 低廉的价格：颠覆是免费的（没有每个席位的费用），优秀的免费文档，在三年的时间里，每个席位每年只需 8 美元，主服务器的硬件和支持成本，廉价的从属 Linux 盒，一次性咨询来自协作网等 al.，由于主从复制，带宽成本低。
- 易于管理：基本上无需管理主服务器：颠覆顾问可以部署所有内容。Sun 员工将更换有故障的硬盘驱动器等。从设备可以是 linux 机器或本地站点上可用的任何管理技能。优秀的颠覆文档。
于 2008-09-16T10:39:04.087 回答
21
在几家拥有 1000 多名员工的公司工作过，我发现他们都使用 Perforce。
我问过“你为什么不使用其他东西？SVN？Git？Mercurial？Darcs？”——他们已经说过（这对所有公司都是一样的）——当他们决定使用Perforce，要么是那个，要么是 SourceSafe，要么是 CVS——老实说，考虑到这三个选择，我也会选择 Perforce。
“更难”的版本控制系统很难获得这么多人的关注，而且当您的大部分软件团队在彼此之间 18 英尺的范围内工作时，DCVS 的许多好处就不那么有用了。
Perforce 有很多 API 钩子供开发人员使用，对于集中式系统，它有很多胆量。
我并不是说它是最好的解决方案——但我至少见过一些非常大的公司使用 Perforce，而且它几乎无处不在。
于 2008-09-15T18:44:09.920 回答
10
Git 是为 Linux 内核编写的，这可能是最接近这种情况的示例，您可以在其中找到公共信息。
于 2008-09-15T18:37:37.707 回答
5
我想说 git，但不要认为这种规模的公司会全部使用 Linux（Windows 对 git 的支持仍然很烂）。所以用 git 之前 Linux 使用的 SCM 即BitKeeper
于 2008-09-15T18:41:26.323 回答
5
截至 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 而不是使用 GUI 的人来说，gitSourceTree是一个很棒的 Windows 和 OS X 应用程序，它为 Git 和 Mercurial 提供了一个干净的界面。hg
过时的建议
截至 2010 年，我推荐Mercurial和TortoiseHG。它是 Windows 支持和分布式版本控制功能的最佳组合。
从 2006 年到 2009 年，我推荐Subversion (SVN)，因为它是免费的并且与大多数 IDE 有很好的集成。对于组织中旅行或更喜欢更分布式模型的人员，他们可以使用 Git 进行所有本地工作，但在想要共享代码时仍然提交到 SVN 存储库。这是集中式和分布式系统之间的一个很好的平衡。请参阅Git-SVN 速成课程以开始使用。使用 SVN 的最后一个可能也是最重要的原因是TortoiseSVN，这是一个 SVN 的 Windows 客户端，任何人都可以通过右键单击访问存储库。在我的公司，这已被证明是向非开发人员提供存储库访问权限的好方法。
于 2008-09-15T19:59:49.710 回答
3
首先，在 CVS 上大 NO。在 2008 年使用 CVS 就像驾驶 92 五十铃 Trooper。他们在路上，人们花钱维护他们的唯一原因，纯粹是出于感性的原因。CVS 是老帽子，技术方面，你会后悔的。
我通常也会避开那种规模的公司的开源工具。Subversion 是一个优秀的小工具，而且非常可靠，但如果你遇到了你不知道的错误，你有责任在 3000 人闲置时修复它。从这个角度来看，Perforce 很便宜，我强烈推荐它。
令我惊讶的是，有多少自称是 SCM 专业人士的人选择“免费”。从表面上看，它看起来很棒，但当您处于困境时，拥有一支高素质的支持团队会有所帮助。当您在周日凌晨 3 点醒来，因为您在新加坡的团队无法做任何工作时，您不会认为“免费”是个好主意。
源代码控制工具是关键任务，您谈论的是公司资产和知识产权。永远不要吝啬源代码控制工具！
于 2008-09-15T21:44:16.633 回答
3
任何 DVCS（BitKeeper、git、Bazaar、Mercurial 等）因为分布式将减少中央“规范”SCM 服务器上的负载。需要注意的是，它们是相当新的技术，没有多少人会熟悉它们的使用。
如果您想坚持使用较旧的集中式模型，如果您负担得起，我会推荐 Perforce，如果您不想为 Perforce 付费，我会推荐 Subversion。我会推荐 CVS 上的 subversion，因为它有足够的功能让它值得，但又足够相似，以至于已经知道 CVS 的开发人员仍然会感到舒服。
于 2008-09-15T18:34:41.597 回答
3
总结：在我亲身体验过 git 的系统中，这些系统处理得最好。
细节：
我曾在多家拥有大量开发人员的大公司工作过。在之前的工作中（我猜大约有 500 名开发人员），我们使用（因为那个时代）RCS 和 CVS。另一组也使用了 ClearCase。ClearCase 小组有严重的问题，但我不知道这是由于 ClearCase 还是由于滥用了应有的 ClearCase 方法，还是由于 ClearCase 管理人员的差劲。
在我现在所在的公司（远远超过 10000 名开发人员，但我怀疑超过 1000 名开发人员在大多数人认为的单个项目中，尽管他们在单个产品上这么多），我们使用了 CVS （由于历史原因）、SVN（因为它是一条简单的迁移路径）、SVK（当时很好，但我不推荐）、Mercurial（抱歉，没有直接经验）、Perforce（同上）和 Git。
除非你被卷入过去并被困在那里，否则我不会推荐 RCS 或 CVS。他们有很好的观点，但与更现代的版本控制系统相比，他们没有什么可推荐的。
SVN 稳定且成熟，分支速度比 CVS 快得多（大型项目只需几秒钟而不是几分钟）。然而，合并这些分支仍然有点原始（在简单的情况下，一个小的 shell 脚本可以让它变得非常容易，但是如果一个分支得到了更新并且有一些东西被拉进来，而且这些东西也被提交到了其他地方，那就很难管理了）。SVN 源代码库似乎也比任何其他开源代码库需要更多的关注和支持（但比商业代码库似乎需要的要少）。SVN 有一个很好的简单概念模型。
然而，你有“几个站点（一些在一个非常慢的链接后面）”，SVN 可以解决这个问题，但它并不能很好地工作。它不仅对“慢站点”的人来说更慢，而且当“慢站点”的人做一些操作时，其他人都被锁定了。尽管如此，我会说 SVN 适用于对中央存储库具有相当良好（快速且可靠）访问权限的组。
SVK 对我们的“慢站点”工作得更好（并且允许更多的“独立工作”）。它对于复杂的合并也比 SVN 工作得更好。SVK 不再维护，否则我会推荐它。
Git 对于大型企业来说相对年轻，值得认真考虑，但除此之外......</p>
它做得很好，但学习曲线相当陡峭。对于已经使用集中式源代码控制系统的团体来说更是如此。在这里有帮助的一件事是将诸如“X 是项目 Y 的权威回购”之类的东西正式化，并采用您所有的旧审查流程等并将它们应用于该回购（如果您曾经需要来自 R 的代码审查和签字测试 T 在检入旧的源代码控制系统的主干之前通过，在提交到权威 repo 的主分支之前需要相同的事情）。
在某些方面，git 实际上比SVN更适合大型团体。您可以通过让少数人能够提交您指定为权威的任何 repo 来强制执行流程。这些人可以负责确保在将更改拉入存储库之前已遵循所有“过程”。Git 甚至会跟踪谁做了更改以及谁集成了它们（SVN 似乎经常出错）。
Git 比 SVN 更便宜地创建分支（你可以断开连接，它不到一秒，而在 SVN 上可能是 3 秒），但尽管大多数人声称这不是一个大问题。最重要的是合并非常容易。即使你已经做了一些事情，比如创建了一个分支，完成了一半的工作，不得不在一个月内做其他事情，更新你的分支中的源代码，因为其他人在一个月内更改了基础项目，然后完成了第二个一半的工作，被搁置了，后来不得不回来发现还有第三半的工作，更多的外部更新，等等……即使在合并之后发现了你的分支中真正新的东西vs. 来自您的更新，并将真正需要合并的内容保持在最低限度。
git 有很多我不喜欢的地方，但它们几乎都归结为“有些工具很锋利，你应该小心”。诸如 SVN 之类的许多不存在的操作之类的事情应该只在只存在于您的存储库中的提交上完成（不要编辑其他人看到的历史记录！）。其他源代码控制系统也有类似的问题，但 git 更强调编辑历史记录以保持其“干净”，因此您需要忽略更多工具和工具选项，或者知道何时安全与灾难。总的来说，我发现它优于我使用过的其他版本控制系统。
我关于 Perforce 的二手信息是“它比 SVN 更好，但不是”。我关于 Mercurial 的二手信息是“它或多或少像 git，除了在细节上，有些人更喜欢它，有些人更喜欢 Git”。
在一家拥有 1000 多名开发人员的公司中，我建议您为所使用的任何源代码控制系统获得一份支持合同。对于 git，我会查看 github:fi。
于 2011-04-24T18:14:01.457 回答
2
好的，完全免责声明：我是一家名为MKS的公司的开发人员，该公司为“企业”公司制作版本控制系统，作为名为Integrity的软件配置管理平台的一部分。Blah blah blah，明显的插头。
所以我不能诚实地回答这个问题。
但是，我想指出，建议分布式版本控制的人缺少一些对大公司来说非常重要的东西。对他们来说，开发人员在处理他们的版本控制系统时有多少灵活性并不重要，重要的是他们对交付的每一行代码都有绝对的控制权。监管合规性和审计比合并的痛苦程度更重要。
一家拥有 1000 多名开发人员的公司想知道每个人都在做他们应该做的事情，没有人做他们不应该做的事情，所有事情都被跟踪，经理们得到可爱的报告和图表，他们可以粘贴到 PowerPoint 幻灯片中为他们的经理。
如果一家大公司不特别关心这些事情，他们更有可能让各个开发团队自己解决问题，在这种情况下，1000 多名开发人员正在使用各种不同工具的大杂烩基于当时看起来最方便的任何东西。
于 2008-09-22T17:32:40.087 回答
2
不要使用 CVS！！如果您想要 CVS 模型，Subversion 是一个更好的选择。
于 2008-09-15T20:10:59.713 回答
1
强制
与 CVS 相比，我喜欢 perforce 的一点是，分支管理必须更加复杂（但仍然相当容易），并且您不需要让中央官僚机构创建分支/标签等。换句话说，它允许单个团队（或开发人员）在提交到由其他人集中管理的主线之前以他们喜欢的方式管理他们的源组件。
哦，我还要说它拥有最好的 GUI 之一，同时仍然拥有一等公民命令行界面。我通常讨厌 GUI，但他们的作品。
于 2008-09-15T19:14:41.690 回答
1
我会使用bitkeeper。我使用过 bitkeeper、clearcase、accurev、perforce、subversion、cvs、sccs 和 rcs，在所有这些 bitkeeper 中，它远远超过了最好的。我玩过 git，它的速度给我留下了深刻的印象，但我认为它的 UI 有点笨重（虽然这个意见是在使用它半天后形成的）。
bitkeeper 的图形用户界面看起来很笨拙，但它们的功能非常强大。bitkeeper 命令行工具可以说是同类产品中的佼佼者，其合并功能绝对出色。
我最喜欢 bitkeeper 的地方（这可能适用于所有分布式系统）是分支非常便宜。创建分支是一种生活方式，而不是令人恐惧的事情。
于 2008-09-15T20:55:53.007 回答
1
如果您有 1000 多名开发人员在开发一个软件，那么您就有资源投资于自己的大量工具。无论您选择什么，您都可能会做大量工作以使其适应您的情况。
Microsoft 的 Team Foundation Server 在 Microsoft 内部的一些非常大的团队中使用，TFS 团队正在努力使其能够很好地扩展。此外，源代码控制和错误跟踪的集成很有吸引力。它并不便宜，而且管理很麻烦，不能很好地缩小到小型团队，但对于您的情况，您可以负担这些费用。当您遇到麻烦时，您可能还希望能够调用像 Microsoft 这样的大型支持组织（但如果您使用免费软件，那么您可以选择在内部提供支持）。
如果您的公司有 1000 多名工程师，但他们正在开发单独发布的软件，我认为您希望将每个软件放在自己的服务器上。这使得性能规模和管理更好。但是，我会坚持只使用一种技术进行源代码控制。
于 2008-09-15T21:55:52.673 回答
1
我会使用AccuRev。我用过 svn、cvs、clearcase (base, ucm)、ccc/harvest，但没有一个能超越 AccuRev 的优势。“拥有多个站点的 3000 多个开发人员组织”？您可以为此使用 Accurev 分布式解决方案 (AccuReplica) - 这意味着您有一个主服务器，并且在远程站点上有任意数量的副本（因此那些具有“慢链接”的人不会受到太大影响）
最重要的是，AccuRev 带来了一种独特的方法——一种基于流的 SCM 工具的真正新概念/设计/实施。不是以 ClearCase-UCM 的（坏）方式做到这一点（因为 ClearCase “流”最终是分支），而是以巧妙的现代方式。
最好自己尝试一下，我知道他们提供 30 天的试用期，并提供足够的许可证来使用该工具 - 尝试一下，您就不会想考虑其他工具了。我的承诺。
于 2008-09-17T20:00:07.617 回答
1
我怀疑您的组织中是否有 3000 名开发人员都在使用相同的代码库。我在一家中大型软件公司工作，我们整个公司可能没有那么多，但也有很多独立的项目。
在内部，一些小组向其他小组提供版本以在他们的产品中使用；这不是通过 SCM 系统管理的。
我们自己的团队有自己的 SCM，但只有大约 25 名活跃的开发人员。我们使用 CVS，老实说，它并没有真正做到（我们会迁移但有很多脚本/提交挂钩和其他需要大量工作来更改的零碎）。在合理大小的代码库上使用 CVS 的问题在于，许多操作非常缓慢并且涉及锁定其他开发人员。
于 2008-09-21T09:14:13.100 回答
1
我会使用任何没有悲观锁定（http://old.davidtanzer.net/?q=node/118）机制的 SCM。特别是因为您希望人们能够在任何大型项目中同时“编辑”同一个文件。
就我个人而言，我会选择带有一些分发解决方案的 SVN，但是由于在 SVN 中您只提交您更改的内容（无论如何每次提交都应该很少），因此网络开销非常小。此外，服务器负载在某种程度上可以用更多的硬件来处理。在使用 SVN 时，我还没有找到硬件扩展的上限。
其他选择可能包括 Linux Kernel 人们使用的“git”，但我对此并没有任何经验。
于 2008-09-15T18:50:21.200 回答
1
如果您有如此大的组织，那么不要强制要求一个特定的 SCM。
我确信他们不会都在使用相同的代码，让团队自己选择他们最熟悉的代码是值得的。
（您可能需要提供一些培训，以便了解如何在 Git、SVN 和一些内部遗留系统之间进行选择。）
于 2008-09-15T18:56:32.480 回答
1
令我感到震惊的是，这里提倡 DCVS-es 的大多数人都被视为某种狂热分子。DCVS-es 被渲染为另一个流行词，就像云计算、社交媒体等一样。
这里的一些人提倡使用 SVN 以及一些特定的硬件设置，特定的磁盘存储应该（甚至能够）带来可靠性。现在这不只是破坏了 SCM 的两个主要目的之一——即确保数据完整性吗？
您没有足够的数据存储级别信息来确保整个源库在所有过去修订中的完整性。如果您希望将数据迁移到另一台机器上怎么办？如果您想在完成之前不停止所有开发的情况下逐步迁移它怎么办？如果存在安全问题并且有人弄乱了您的主副本怎么办？你如何找到最后一个有效的？存储完整性只能让您做到这一点，并且不会让您解决任何这些问题。正是因为它在不适当的抽象级别上运行。不是您关心的存储。这是你的代码库。
另一个问题。有些人无法相信实际上有可能让 3000 多人在同一个项目中进行操作。他们说“去烤你自己的 scm”，我想这是另一种表达方式“是的......对...... 3000 多个开发人员......祝你好运”。同时，也有涉及更多人的项目。从工程到法律，几乎可以做任何事情。但不知何故，当涉及到软件开发时，这是不可能的，不可能。这个想法（我想）是这样的：什么？3000 多人接触同一个文件？现在，那不可能。而且，是的，它是正确的。不可能。问题是你为什么要让 3000 多人接触同一个文件？在自然界中，你会在哪里找到这样的情况？3000 多名律师是否会互相发送一份文件，直到他们最终就所有事情达成一致？人们不是那样工作的。在现实中永远不可能像那样工作。然而，从理论上讲，集中式 CVS 使之成为可能。更糟糕的是，它迫使人们实际上与他们甚至不认识的人协调他们的工作。在这种情况下，即使有聪明的人加入也不是问题，尽管我想在成千上万的人中很难保证每个人都不是白痴。这只是关于犯常见的愚蠢错误。每个人都会犯错误（字面意思）。你为什么突然想把这件事通知整个公司？不能那样工作。在现实中永远不可能像那样工作。然而，从理论上讲，集中式 CVS 使之成为可能。更糟糕的是，它迫使人们实际上与他们甚至不认识的人协调他们的工作。在这种情况下，即使有聪明的人加入也不是问题，尽管我想在成千上万的人中很难保证每个人都不是白痴。这只是关于犯常见的愚蠢错误。每个人都会犯错误（字面意思）。你为什么突然想把这件事通知整个公司？不能那样工作。在现实中永远不可能像那样工作。然而，从理论上讲，集中式 CVS 使之成为可能。更糟糕的是，它迫使人们实际上与他们甚至不认识的人协调他们的工作。在这种情况下，即使有聪明的人加入也不是问题，尽管我想在成千上万的人中很难保证每个人都不是白痴。这只是关于犯常见的愚蠢错误。每个人都会犯错误（字面意思）。你为什么突然想把这件事通知整个公司？甚至不是让聪明人加入的问题，尽管我想在成千上万的人中很难保证每个人都不是白痴。这只是关于犯常见的愚蠢错误。每个人都会犯错误（字面意思）。你为什么突然想把这件事通知整个公司？甚至不是让聪明人加入的问题，尽管我想在成千上万的人中很难保证每个人都不是白痴。这只是关于犯常见的愚蠢错误。每个人都会犯错误（字面意思）。你为什么突然想把这件事通知整个公司？
现在有些人可能会说 - 但您不必向所有人授予提交访问权限。嗯 - 那是作弊。在集中式环境中构建分布式工作流，这完全是一种无望的尝试。突然你有一个两级树 - 具有提交访问权限的人发送所有那些没有提交的工作。好吧，如果你走得那么远，为什么不就不可避免的问题达成一致——没有也永远不会只有整个源代码库的单一通用版本。人们需要在他们分离的环境中工作，这些环境可以很容易地融合在一起。
现在有很多 DCVS。只有 Git 有这种跟踪内容的方法，而不是单个文件，在这种情况下，这可能不是最佳选择（但它在很大程度上取决于项目的组织）。还有 Mercurial，还有 Bazaar。所以这两个属性不相互依赖。
我真的不想推荐任何特定的 DCVS，我觉得没有那么有能力。然而，在大多数推荐的解决方案都没有分发的情况下，不确保数据完整性，实际上比根本没有任何 CVS 更糟糕，我觉得我需要写一些东西。真正的问题应该是哪个 DCVS 最适合完成这项工作。
于 2011-04-24T20:21:17.330 回答
0
让我们看看选项。
1 - 强制执行。许多公司（正如人们所说的那样）使用 Adobe、Amazon、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 / 任何旧的
于 2008-11-04T14:35:40.207 回答
0
如果您的意思是 3000 多名开发人员在同一个代码库上工作，我不知道。如果您的意思是在不同地点从事数百个项目并且您需要有一个标准，那么我会选择在大量在线用户支持下流行的东西，即不是让您在 Google 上获得 10 次点击的晦涩难懂的东西。
就我个人而言，我会选择 SVN，我在一个拥有数百名开发人员的 IT 部门，并且最好的源代码控制应用程序是 SVN。
:)
//W
于 2008-09-15T20:50:04.720 回答
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（它们本身都不好）
于 2008-09-15T23:38:35.610 回答
0
我实际上会检查 Team Foundation Server。这是一个非常好的系统，可以扩展，并且很容易通过内部 IT 部门。我知道它以 Windows 为中心，但您也可以为 Linux/Mac 使用附加组件，并且您可以为一些连接速度较慢的站点使用代理。
而且我会考虑在一个大型组织中拥有 2 个系统，这可能有助于在某些单独的情况下获得最佳效果。
于 2008-09-15T23:06:47.607 回答
0
Perforce 和 TFS 是我所知道的唯一选择。我知道它们都已在 Microsoft 的大型项目中使用过。Vault可能会扩展那么大，但我不知道它是否超过 500-1000 个用户。
于 2008-09-15T23:14:25.920 回答
0
Adobe 使用 Perforce
于 2008-09-15T18:36:29.503 回答
0
Perforce 是一个不错的系统，并且可以很好地扩展。
我在一个拥有大约 5000 名员工的组织中工作，而 perforce 是一个快速高效的系统。它可以很好地扩展，具有良好的分支支持，具有原子提交。每个更改都有一个更改编号，可用于“软件考古”和许多其他出色功能。
此外，它对 windows、mac 和 unix 有很好的支持，包括很好的命令行和很好的脚本支持。
我以前使用过 CVS，它不能很好地扩展到超过 25-50 名工程师的团队（主要是因为原子操作和性能）
于 2008-09-15T19:30:57.623 回答
0
Perforce 也得到了我的投票。我没有在这么大的项目中使用过它，但它在我的环境中绝对坚如磐石。它还拥有令人印象深刻的大型项目履历。
[谣言]我听说微软将它用于 Vista。[/谣言] 显然它是为他们定制的版本，但它并没有比这大得多。
于 2008-09-15T23:56:44.897 回答
-1
Subversion 易于扩展和拆分。Perforce 只为少数员工花费数千美元，非常昂贵，此外，它没有提供颠覆不提供的任何东西。
Subversion 真的很简单，比 cvs 好。
如果只有他们的 Windows 支持更好，我会推荐 git
于 2008-09-15T21:02:04.240 回答
-1
对于使用 Visual Studio 的开发人员，我强烈推荐带有 TortiseSVN 客户端和 Visual-SVN 插件的 SVN。
于 2008-09-21T08:50:25.577 回答
-1
我会使用颠覆。Subversion 已在具有大型开发人员社区的许多大型分布式开源项目中得到证明。此外，Subversion 提交的事务性质使其非常适合连接可能不可靠的情况。
于 2008-09-16T00:37:58.447 回答
-1
如果他们都在开发同一个产品，可能是 Perforce。
如果有很多较小的项目（2 到 50 个），我会运行几个 Subversion (SVN) 机器。
于 2008-09-15T19:29:42.200 回答
-1
在我们公司，我们使用 alienbrain，但我们正在迁移到 Perforce。Perforce 拥有您想要的一切：它处理代码和数据，他集成了用于持续集成的工具，它处理本地（每个开发人员）存储库，因此您可以在提交到服务器之前签入本地存储库。
我投票给 Perforce
于 2008-09-15T21:34:23.710 回答
-1
带有 TortiseSVN（在 Windows 上）的 SVN 非常棒。我强烈推荐它。
于 2008-09-16T00:01:29.080 回答
-1
我是 Subversion 的粉丝，但有很多不错的开源和闭源选择。我会避免使用 CVS，因为它确实不像现代 SCM（没有原子提交等）。
有人可能会建议 SourceSafe。像瘟疫一样避免它。SourceSafe 默默地摧毁了历史，造成了无尽的悲痛。一点谷歌搜索会告诉你更多关于这一点。
Subversion 很成熟，有很多很好的工具和 IDE 集成。它在大多数网络上运行良好，因为它使用 HTTP 访问存储库。
几年前我进行了 SCM 转换，你能做的最好的事情就是尝试一下。SCM 供应商将为您的评估提供演示和技术支持。
选择 SCM 并不是一件容易的事。这实际上取决于您的代码库和工作流程。一些系统比其他系统更好地处理庞大的代码库。有些处理大量的分支和合并比其他更好。有些比其他的更适合远程访问。有些具有更细粒度的安全模型。
让所有将与系统交互的人一起列出你需要/想要的东西。获取演示并将您的代码导入其中并尝试一下。为这么大的团队选择 SCM 是一个重大项目，应该这样对待。
于 2008-09-16T00:03:43.693 回答