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

#1 楼

理由可能不像从前那样重要，但是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）中，免费解决方案可能存在一些实际限制。

#2 楼

无论是作为用户还是在设置和维护服务器方面，我都相当精通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可以很好地工作。它们每个都可以在适当的环境下正常工作。

#3 楼

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

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

#4 楼

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


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

#5 楼

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


Perforce很快。比Subversion或Git快得多。
Perforce合并比Subversion或Git更好。 Git并没有真正做到合并，而且Subversion的版本跟踪也不太好，至少在1.5版本中是如此。
Perforce拥有出色的客户支持。
Perforce将Subversion的存储库修订与单个文件修订结合在一起。 Perforce允许您通过更改列表或单个文件版本查看存储库修订。
与多个版本列表相比，Perforce的工作要好于Subversion。 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并不是最终的工具。在不需要集中控制谁可以访问存储库的情况下，它非常有用。但是，在许多情况下可能会很痛苦。我这样说：


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

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

我并不反对Git。我在很多情况下都推荐了Git。其中包括彼此之间联系不畅的分布式团队，或者您不想追踪有权访问源存储库的所有人的地方。例如，某大学的计算机科学系希望获得他们的支持。学生使用源代码管理，并将代码放置在此处以供老师查看。好点子。太多的孩子在不了解标准的构建和开发程序的情况下离开大学。我推荐了Git。

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

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

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

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

#6 楼

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

猜猜这些地方没有FOSS产品吗？

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

另一个原因是由于成熟。我们今天使用的某些产品直到最近才稳定到足以用于严肃的业务用途，有些产品没有支持选项，有些产品没有作为业务解决方案的可靠记录。这些是需要考虑的重要问题（尽管作为技术人员，如果使用它们并使它们失败的风险对于保持业务正常运行的影响很小，我将很乐意评估FOSS解决方案），并且一些管理人员应该谨慎地避免这些问题。他们对老板负责，如果产品背后有支持组织，他们会感到很自在-毕竟，您有一个为您的业务服务的组织。 （例如Collabnet或SVN的Wandisco），它仍然获得“极客在他们的后卧室制造”的声誉。我们都知道这通常是最好的，而最好的FOSS与商业产品的竞争非常之好，但是我的经理仍然需要说服。也许他只是没有意识到未成熟和成熟的FOSS产品之间的区别；也许他不在乎。

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

#7 楼

因为像Perforce这样的工具有推销员来酒和用餐，而Git却没有。当然，这只是我说话时的玩世不恭，但这是近距离观察过程带来的一种犬儒主义。

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

#8 楼

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

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

#9 楼

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

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

#10 楼

因为SVN可以说是SVN和Perforce（比起工具，在4年前就曾有过）在某些方面比SVN更好。 （分支是我认为的其中之一。）

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

#11 楼

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

就某些棘手的，粗糙的软件（Serena Dimensions）的选择而言，它说在巴哈马群岛举行的几轮比基尼高尔夫比赛以及几名20多岁的女性销售人员可以说服总监或副总裁几乎所有内容。

#12 楼

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

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

#13 楼

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

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

#14 楼

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


典型用法的性能，特别是对于远程站点
资源需求
工作习惯中所需变更的重要性
支持可用性和成本

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

#15 楼

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


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

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

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

ClearCase基于RPC构建，由于大量的小型网络数据包被“往返”，RPC无法在广域网（仅互联网）上运行良好，IBM和Rational都将ClearCase视为“

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

总而言之，perforce可以“立足于“门”，因为其他选择不多，而且还没有弄得一团糟，人们无法离开。