大公司为何使用Perforce？[关闭]

我听说一些大公司，例如Google，Facebook使用Perforce

SVN / Git无法替代Perforce吗？

理由可能不像从前那样重要，但是Perforce在大型存储库上的表现往往要好于Subversion。这是Microsoft获得Perforce的源许可证以构建Source Depot的原因之一。NT的存储库是一个庞然大物，没有很多产品（商业或其他）可以处理它。

另外，至少一次，Perforce的可视化工具比Subversion或Git的开箱即用（可以说）更好。如果您使用的是Meld，那么也许这些事情比以前更重要，但是Perforce仍然有一些非常出色的功能，包括可视化的分支和合并，尽管我没有详细的记忆，因为它已经自从我上次接触Perforce大约3年以来，这似乎比Github的方法要复杂得多。

一旦使用了Perforce，您可能会了解它在实践中的优势。他们长期以来一直提供免费的两用户服务器选项，并且根据您所使用的源代码管理系统的经验，在团队测试了一段时间后，您可能会发现值得花升级的成本。对于较小的商店，这加上使用它并喜欢它的开发人员的网络效应，是Perforce最终获得付费用户的原因。与德米特里（Dmitri）的愤世嫉俗的言论相反，在拥有小型开发团队的公司中出售Perforce的CTO可能不会有很多获胜者和取胜者，但这种做法经常在这种地方使用。

我在Microsoft以外从事的大多数项目都可以由Git，Mercurial或Subversion合理地很好地服务，我会说我工作过的大多数公司都使用了其中一种选择。但是有一个优点，通常是存储库大小，分支和合并模型以及团队经验/历史的结合，导致人们使用商业工具。例如，我很少见到大型的Git存储库。这可能不是由于Git的任何固有限制；我承认那完全是无知的。但是在某些项目（例如Windows NT）中，免费解决方案可能存在一些实际限制。

作为用户以及设置和维护服务器，我对svn，git和Perforce都相当熟练。

对于一家公司，甚至像我这样的孤独程序员来说，源代码管理是支持开发和销售代码的真正赚钱活动的成本。因此，有几个因素需要考虑：

• 它与您的开发模型的适应程度如何？
• 开发人员学习和使用有多容易？
• 开发人员的日常操作是否很快？
• 使用它的过程是否分散了他们的实际工作，即编写代码？
• 设置和维护有多容易？
• 购买和维护需要多少费用？
• 如果需要帮助，获得帮助有多容易？

我将跳过有关各个系统优缺点的tl：dr详细信息。可以说，当我去年回到全职咨询时，我对这三个方面进行了审查，以决定哪一项可以通过向客户提供优质软件而使我尽可能快地赚钱，而又不需要大量的未付费用无所事事。当我从政治上考虑“ FOSS很好，而非FOSS却是邪恶的”时，我为Perforce许可证付出了巨大的努力。

这就是大公司也选择Perforce的原因。

这是注释中的tl：dr详细信息，还有更多内容。

解决svn很容易：与Perforce相比，它速度慢。我在一家为手机嵌入Linux的公司工作，我们的完整资源运行9 GB。他们使用了Perforce。获得代码后，通常在LAN上花费数秒钟即可更新最新的资源，而从我家通过VPN连接花费几分钟就可以了。使用svn，分别需要数分钟和数小时。

git vs. Perforce更复杂。许多公司认为他们有充分的商业理由要使用具有访问控制功能的集中式存储库，并使其易于在此进行提交而很难执行其他任何操作-Perforce完全适合该模型。但是，git积极地鼓励人们在本地分支机构工作，并且没有办法使它在任何方面都不同。开发人员可以完全在本地分支机构工作，而从不参与中央仓库-因此，如果公司不希望其员工以这种方式工作，Perforce是一个更好的选择。

对于某些业务需求，git还有其他问题。我在一家使用git的公司工作，但我不知道我听到过多少次讨论：“我希望我们使用[其他VCS]，因为我需要这样做[并且]我不能使用git 。” “当然，您可以使用git来做到这一点。” “怎么样？” “好吧，首先您需要编写一个bash脚本...”“没关系。”

然后需要花一些时间来初始填充具有很多历史的源代码树。使用Perforce，由于历史记录保存在服务器上，因此您只需获取所有文件的最新版本，因此它的速度非常快-甚至设置了我提到的整个9 GB树仅通过VPN花费了几个小时。使用git可能需要很长时间到永恒。有时我不得不克隆GTK +或X服务器的git repos，那是一个漫长的午休时间，或者也许是上床睡觉的时间。

确实，这是工作所需的正确工具。svn对于Apple的大多数开放源代码工作都可以正常工作，并且对于内核黑客攻击非常糟糕。git对于GTK +来说非常有用，但是在WebKit中使用它的速度却非常慢-源代码树和历史记录太庞大了（正如我发现从WebKit的svn-to-git门户中使用代码的艰难方式）。如果您有庞大的源代码树并且需要集中控制，则Perforce可以很好地工作。它们每个都在正确的环境下运行良好。

特别是GIT和SVN在一定程度上还不算老-如果您在90年代中期需要可靠的版本控制，您几乎必须要商业化，因为SVN处于起步阶段，而CVS就是CVS。一旦您对系统进行了大量投资，移动它可能会很麻烦。

哦，做出这些决定的人可能永远不会与版本控制系统进行交互，但是确实会被上述销售人员喝醉并用餐。

我从事游戏行业的程序员已有将近9年，而我从事过的每个项目都使用了Perforce。我怀疑有一些因素使Perforce继续在该特定行业中使用。

• 人们使用Perforce已有很长时间了，并且对此感到非常满意，因此他们不愿切换到其他解决方案。决策者可能还会犹豫，将他们3,000万美元的项目交给他们从未使用过的软件。
• 许多公司/团队已将Perforce支持添加到其内部工具中，这可能需要大量工作才能进行更新以支持另一个VCS。
• 尽管程序员可能很容易将时间切换到另一个Git / Hg / SVN，但是游戏开发团队的技术人员却很多，例如艺术家，设计师和制作人。让他们适应新系统可能会花费很多时间，我敢打赌他们会坚决抵制这种变化。

也许，也许他们喜欢Perforce是因为Perforce更好？

• Perforce很快。比Subversion或Git快得多。
• Perforce合并比Subversion或Git更好。Git并没有真正做到合并，Subversion的版本跟踪也不太好，至少在1.5中是如此。
• Perforce具有出色的客户支持。
• Perforce将Subversion的存储库修订与单个文件修订结合在一起。Perforce允许您通过更改列表或单个文件修订来查看存储库修订。
• 与多个Subversion相比，Perforce在具有多个更改列表方面做得更好。Subversion的变更列表有些事后才想到，使用它的人很少。Perforce是内置的。如果从默认更改列表中移动更改的文件，则不会意外提交该文件。
• Perforce允许您指定工作目录的布局。例如，如果您有一个标准的源代码目录树，但是有些客户有自定义源，则可以将自定义源覆盖在标准树上。您只需指定要结帐的项目即可轻松进行稀疏结帐。

好的，在您以为我是Perforce Fanboi之前，我上一次向公司推荐Perforce的时间是7年前。Perforce每个许可证的价格为800美元-与ClearCase相比便宜，但与Subversion相比价格昂贵。我很难证明Perforce优于Subversion。

另外，大多数开发人员都习惯使用Subversion。他们不想学习Perforce，它与Subversion具有不同的工作方式。在Perforce中，您必须创建一个客户端，并且必须标记文件以进行编辑，然后才能对其进行修改。您不必使用Subversion做到这一点。

与Perforce over Subversion的集成也较少。部分原因是由于使用了客户端。它只是不能与VisualStudio甚至Hudson配合使用。部分原因是Perforce必须创建客户端集成。

专有许可证的费用称为管理费用。想象一下，如果您可以为每位用户$ 1.00的价格许可某个软件。哎呀，让我们做两点。成千上万的许可证只需花费250美元。

现在，您需要一个专职人员来管理许可证。一个普通的技术工人在一家公司呆了大约2年。这意味着每年将有500人离开，另外500人将离开。每周必须有十个人必须更改许可证。然后，有时项目启动，您需要另外250个许可证。必须对它们进行订购，输入和维护。这可能需要数周的时间。

这就是为什么许多商业公司转向开源的原因。这不是许可证的费用。您每年向开发人员支付15万美元，而Perforce许可证又需要800美元呢？它正在管理该许可证。与ClearCase相比，Perforce看起来很棒：更快，更容易，更便宜，更好。但是，反对Subversion吗？Perforce可能会更快甚至更好，但会提高800美元吗？更好地管理许可证吗？它不是更好地使用所需工具吗？

因此，Perforce可能会出现问题。

Git并不是最终的工具。在不需要集中控制谁可以访问存储库的情况下，它非常有用。但是，在许多情况下可能会很痛苦。我这样说：

1. 您运行一个开源项目。如果有一百万个人拥有整个存储库的副本，您会感到高兴还是沮丧？
2. 您正在运行一个使用专有软件的金融交易中心，以在您的竞争对手中占优势。如果有一百万个人拥有整个存储库的副本，您会感到高兴还是沮丧？

如果要进行集中式构建，则无论如何都需要每个人都使用一个存储库。在这种情况下，分布式系统的优势是什么？实际上，它可以鼓励人们离线工作。开发人员可能只是简单地以自己的方式离开，直到最后一刻才做出任何承诺。然后，您花了两个疯狂的日子来尝试使所有功能重新运行。

我不反对Git。我在很多情况下都推荐了Git。这些包括彼此之间连接不良的分布式团队，或者您不想跟踪有权访问源存储库的所有人的地方。

例如，一个大学计算机科学系希望让他们的学生使用源代码管理，并将其代码放在那里供老师查看。好想法。太多的孩子不了解标准的构建和开发程序就离开大学。我推荐了Git。

通过使用Git，存储库的管理员只需从他们的同伴那里进行提交即可。他们不必担心个别学生。教授可以允许学生提交其版本库。学生可以分组学习，每个小组可以共享他们的版本库。

如果学院使用Subversion，则有人必须了解所有学生，并向他们授予对中央存储库的所有访问权限。他们必须管理谁可以检查什么地方。如果教授分配了小组项目，则必须进行设置和管理。您需要专职人员来进行管理。

这不是一支球队比另一支球队更好的足球比赛。工具以不同的方式工作，每种都有其优缺点。Perforce是一个很棒的工具。不幸的是，已经出现了难以推荐的情况。

Git很棒，但是我仍然依靠Subversion来创建我的个人源代码库。毕竟，我不分享它，并且Subversion更易于使用。如果我的团队很小，我会使用Git进行个人工作，因为我不必在Internet上全时保持我的存储库。对于大多数商业网站，我仍然发现Subversion效果最好。但是，在某些情况下，Git会发光。

我不知道“酒与饭”贿赂是否仍然适用，但是对于大多数管理者来说，当他们决定寻找一种产品时，会在各种出版物中读到（针对管理），并查看宣传该产品的小册子和小册子。美德。

猜猜，那些地方没有FOSS产品！

因此，几乎可以肯定的是，大多数管理采购决策都是由广告和营销驱动的。他们可能会执行评估，但是会评估其中一些产品。

另一个原因是由于成熟。我们今天使用的某些产品直到最近才足够稳定，可以用于严肃的业务用途，有些产品没有支持选项，有些产品没有作为业务解决方案的可靠记录。这些是需要考虑的重要问题（尽管作为技术人员，如果使用它们并使它们失败的风险对于保持业务正常运转的影响很小，我将很乐意评估FOSS解决方案），并且一些管理人员应该谨慎地避免将它们存在。他们对老板负责，如果产品背后有支持组织，他们会感到更加自在-毕竟，您有一个可以为您的企业服务的组织。

最后，尽管许多FOSS产品确实有支持（想想SVN的Collabnet或Wandisco），但它仍然获得“极客在他们的后卧室制造”的声誉。我们都知道这是一般B * * **吨和FOSS竞争令人难以置信的商业产品是最好的，但我的经理仍然需要被说服。也许他只是没有意识到未成熟和成熟的FOSS产品之间的区别；也许他不在乎。

无论如何，Perforce是一个很好的SCM，没有理由不选择它。对于其他SCM，我可以说同样的话，但在那之后，我只能说一些关于其他SCM的坏话，并且在涉及某些特定产品时仍然会做噩梦。

因为诸如Perforce之类的工具具有推销员来用餐并负责购买的人，而Git却没有。当然，这只是我说话时的玩世不恭，但这是近距离观察过程带来的一种犬儒主义。

只是为了清楚起见：我并不是说您每次看到CIO都醉在大街上时，都希望在下个季度使用新的版本控制系统。只是许多组织在使用和获取之间存在脱节。当然，公司使用Perforce还有其他原因：例如，他们可能已经在其工作流程中的实施上投入了大量资金。但是总的来说-这个问题非常普遍-不使用FOSS工具没有功能上的优势。

我的公司拒绝使用许多开源软件的原因可能与此相同（我不同意）：

当出现问题时，他们希望有人可以打电话并大喊大叫。

尽管所有答案都涉及使用P4的大公司（它们回答了Google为什么使用P4的原因），但Google继续使用Perforce的主要原因之一是Perforce允许您签出仓库的子树，而Git则不能。像Google这样的大型资源库可以发挥很大的作用。

据我所知，Facebook使用SVN和Git-SVN

因为SVN很好，所以SVN和Perforce（比起工具来早4年）在某些方面比SVN更好。（我认为分支是其中之一。）

和分布式一样，GIT是Dvcs 。对于公司团队而言，分散部分可能是无关紧要的。

大公司倾向于购买大型，笨拙的“企业”版本控制系统的另一个原因：

IT部门的中高层管理人员将VCS视为每个项目都使用的东西，或者您可以强制使用它。强制使用VCS之后，为什么不在那里也添加一些“流程”呢？我的意思是，您有机会指定一个“企业级”系统，为什么不将其置于中央控制之下，并添加“灾难恢复”和一些“工作流功能”，因此您可以说“我们是CMM Level StraightJacket符合！”。VCS太容易成为目标，因此无法采用工作流执行功能。

至于某些变态的，粗糙的软件（Serena Dimensions）的选择，据说在巴哈马的几轮比基尼高尔夫运动以及几名20多岁的女性销售人员可以说服总监或副总裁。

大公司需要某种集中式模型。开发人员完成开发后，便会移交给客户支持。当他们必须梳理50-200个分布式开发人员存储库时，您真的要穿上支撑鞋吗？并且构建是基于中央存储库完成的，构建必须始终，始终，始终可追溯和可复制。当您第一次因某种愚蠢的专利侵权而上法庭时，就会学到这一点。

Git在此模型中效果不佳。如果您的公司规模较小，或者VPN访问能力较差，那才是真正的亮点。

大多数大公司使用Perforce的原因之一可能是IT部门有更多的专业人员，他们对此有很多了解，并且有多年解决相关问题的经验。

我觉得将来公司可能会开始从Perforce转移到GIT ...我知道的大多数开发人员似乎都更喜欢它！另请访问http://whygitisbetterthanx.com/#git-is-fast，以获取有关为什么Perforce在未来几年内可能不那么占主导地位的更多证据！

以前，我们从一组VCS（我肯定知道以前使用过RCS，CVS，ClearCase，Perforce，也可能还有其他）切换到Perforce作为正在使用的独特系统。那不是一个小项目：迁移花费了一年的时间。负责团队（我不是团队成员）评估了多个VCS，并且至少考虑了git和svn以及已经使用的那些。我记得他们的报告，他们过滤掉了没有所需功能的工具，然后考虑了：

• 典型使用情况下的性能，特别是对于远程站点

• 资源需求

• 改变工作习惯的重要性

• 支持可用性和成本

Perforce总体上是一个明显的赢家。git在第一点上略胜一筹，但在其他方面则处于劣势。

曾几何时，不久前（IDE被称为VI）时，唯一的免费（开源）系统是CVS，RCS和SCCS。

• 这些都无法很好地解决文件重命名的问题。
• 他们没有记录合并，因此如果两个分支都在积极工作，则很难合并，直到在一个分支上完成工作为止。
• 它们无法很好地扩展到非常大的代码库
• 他们没有提供大型项目所需的访问控制和流程通知者级别。

那里有很多商业源代码控制系统，其中大多数是由单个机器供应商（IBM，DEC，HP等）提供的，并且只能在其硬件上运行。

然后，一些公司表示要出售包括Perforce和ClearCase在内的跨平台商业源代码控制。

ClearCase基于RPC构建，由于许多小型网络数据包被“往返”，RPC无法在广域网（仅互联网）上运行良好，IBM和Rational也将ClearCase视为“摇钱树”，但从没有表现出来爱。

因此，唯一仍普遍使用的“旧”商业源代码控制系统是Perforce。一旦使用了perforce并将其集成到构建系统和错误跟踪系统中，公司迁移到其他产品几乎不会带来短期利益。

因此，总而言之，在没有太多其他选择的情况下，perforce便成为了“门口之门”，而且它们还没有弄得一团糟，无法让人离开。