Perforce有哪些优势？

Question

Perforce有哪些优势？

svnversion-controlperforce

26

Perforce有哪些好处？

我想了解一下，在某些情况下，Perforce如何比Subversion更有效。

如果您既有Perforce的经验，也有Subversion的经验，并且认为没有任何优势，或者认为svn比Perforce更具优势，我也想知道原因。

- user32677

2

Perforce非常好用。我曾经使用过SVN、Visual Source Safe和其他系统。我也使用Perforce已经有几年了。我不会在任何其他系统上运行商业项目。 - Jonesome Reinstate Monica

9个回答

16

Perforce的一个重要卖点是速度。服务器跟踪客户端上文件的状态，因此像“获取最新部署状态”这样的操作非常简单-服务器已经知道你拥有哪些文件，并且可以将最小的信息发送回给你。

这种优势也带来了一个缺点，即如果您在没有首先检出文件的情况下本地编辑文件，本地移动文件而没有进行集成或删除文件，则服务器和客户端可能会不同步。

由于Perforce服务器仅向客户端发送最少量的数据，因此在较慢的连接上性能良好，例如美国客户端访问伦敦部署的情况。尽管如此，Perforce协议相对来说比较‘啰嗦’，因此在拥挤的连接上容易受到减速的影响。

- Tim Robinson

1

我同意你所评论的缺点，特别是如果由于某些原因无法连接到服务器。不过，让Perforce解决这个问题很容易： https://dev59.com/enVC5IYBdhLWcg3whRgw - user5722

Perforce的一个重要卖点就是速度。嗯...目前我正在进行一次大型集成，已经合并了五个小时的内容... - Calmarius

1

@Calmarius 升级服务器上的磁盘。Perforce网络流量被设计为快速，但它会占用所有可用的服务器资源。特别是，集成受益于快速I/O。 - Tim Robinson

@TimRobinson 如果你的集成变更列表包含千兆字节（因为我们公司的某个失败者决定在p4中存储二进制文件），它将下载所有需要集成的文件，似乎没有选项告诉Perforce不要这样做...（至少在这个古老的2009.2服务器上）。 - Calmarius

@Calmarius 很抱歉听到这个消息 - 我想你被卡住了。希望检入二进制文件的人在你等待时给你买杯咖啡... - Tim Robinson

显示剩余2条评论

11

我每天在工作中使用Perforce，但我不建议任何人使用它。我确定它或许曾经是多年来最好的SCM，但它的核心模型已经过时了。

Perforce可能是我使用过的最为集中化的SCM系统。想象一下，他们以不在你的磁盘上缓存任何内容而自豪。进行同步操作很麻烦，因为在许多情况下，除非你强制同步，否则什么都不会发生 - 而强制同步会将所有内容从服务器复制回来 - 如果你的项目有10GB，它将全部复制。

我之前使用过SourceSafe、CVS、SVN、Mercurial和git（后面两者用得较少）。

我认为大多数开源SCM都很成熟，你可以选择其中之一。如果你想要一个集中化的，请选择SVN；如果你想要一个分散式的，请选择Mercurial（我在Windows上使用git有不好的经历）。

我使用perforce时遇到的其他问题:

你提交的不是你收到的: 例如，如果你在Intel Mac上提交了UTF16文件，并在另一个PPC Mac上同步，你将得到另一个UTF16文件，因为perforce是聪明的，并将文件转换为客户端字节顺序。UTF16-BE - UTF16-LE ?!
编写perforce脚本比其他工具难多了。
如果你开始使用它并将其与你的流程绑定，通过编写脚本来实现，那么可能你会为之而死，因为所有事情都是按照perforce的方式以及perforce的方式来完成的 :(
想象一下，让p4服务器崩溃非常容易: 只需在项目根目录上执行同步操作即可。在我工作的地方，这是不允许的，因为它会使服务器崩溃！有一个监视脚本正在监视perforce服务器进程，如果其中一个进程占用了超过x GB的RAM，它就会将其杀死并发送通知给你。是的，在客户端上执行一个简单的命令可以在5-10秒内在服务器上创建一个3GB的进程。

- sorin

3

我不同意你在这里提出的几乎每一个观点。文件编码是可配置的，如果你没有正确设置Perforce，那不是他们的错。脚本编程很棒，并且支持如Java/Python/Ruby/.NET等许多语言，入门门槛相当低。SCM的脚本编写几乎总是根据所选软件进行定制，我想不出任何一种情况不是这样的。关于关闭服务器的评论我无法发表真实看法，因为我从未见过这种情况，即使在英国和澳大利亚之间同步整个仓库。 - ninesided

1

我尊重您的意见，但不要忘记，“整个仓库”在不同公司可能会有很大的不同。我在一个单一的仓库中有大量文件（6位数！）和超过30GB的数据。 - sorin

1

@sorin 不确定你们公司的Perforce设置如何，但我们在我们的仓库中托管了超过7位数的文件，而你所说的从未发生过。有些事情告诉我，你的配置出了问题。 - CodingMadeEasy

8

Perforce与svn有些不同。在你的工作副本中，每个文件始终处于锁定状态，你必须向perforce声明你将开始编辑它。

这有一个优点，即你可以立即看到谁正在编辑文件。

总的来说，与其他SCM相比，差异并不是很大。你会在许多地方遇到Perforce，因为在某个时候，它是少数（如果不是唯一）在Windows和Mac上运行的部分合理的SCM之一。

如果我没记错的话，你可以免费使用它，但客户端数量有限，所以你可以轻松尝试它...

- Pieter

锁定未被强制执行，仅限于无法合并的二进制文件。虽然如此，多个人可以同时在同一个ASCII文件（例如源代码）上工作，之后再将它们合并。 - steffenj

2

Perforce有一个免费的2开发者许可证。 - riadd

从Perforce获取临时许可证供您的团队测试也非常容易。只需打电话询问，您就可以免费获得大约需要的许可证，有效期为30或60天。 - user5722

您可以配置Perforce工作区，以在编辑之前不需要检出文件。这是工作区规范的一部分。 - Br.Bill

6

个人而言，我讨厌Perforce。它的用户界面很糟糕、复杂，并且非常不直观。它有错误和经常崩溃。

我之前使用过SVN（通过Tortoise SVN），发现它更简单友好。

当然，这些都是从用户的角度来看的，可能SCM有不同的观点。

- Yuval A

8

我完全不同意。我过去6年一直在使用Perforce工作。系统几乎不会崩溃，或许5年前会有，但如今的Perforce非常稳定。你需要学习界面操作，或者你可以直接使用更新的P4V，它拥有更符合“Windows”的用户界面。 - steffenj

2

我会向您指出 P4WSAD（Perforce-Eclipse 集成），但它存在很多漏洞。无论如何，用户体验是完全客观的，因此在我的回答开头加上了“个人意见”这一短语。 - Yuval Adam

5

我认为仅凭一个可选插件的优点（或缺点）就评判整个源代码管理(SCM)系统是不公平的。我每天使用带有Java的Perforce，但没有安装该插件。我只需在Eclipse之外处理源代码控制。很容易。 - ninesided

1

Perforce客户端（Windows）从未崩溃过。 - C.J.

1

是的，Eclipse与许多东西的集成都存在严重的错误。基于这个特定的用例来评判一个工具有点不公平。 - Br.Bill

@CJohnson 它不会崩溃，但经常出现问题，停止响应（即使服务器正常运行，仍然持续等待服务器）。在这种情况下，“取消”按钮无法工作，因此您必须重新启动（通常需要强制关闭应用程序才能重新启动）。另一个经常发生的事情是，在运行一段时间后，它会卡住并开始占用一个核心的100％ CPU，您必须将其杀死。也许不是崩溃，但绝对不是稳定的应用程序，您不能一直让它运行。 - Brandin

5

你可能会在使用Perforce而不是Subversion的好处中找到一些提示（只是按照您的Perforce标签进行跟踪...）。

我们在工作中使用Perforce，虽然我对各种SCM软件经验有限，但我认为这个软件做得非常好，具有良好的GUI（在Windows上），良好的命令行支持和许多不错的功能...可能需要一段时间来适应它的逻辑，但我认为对大多数SCM也是如此。

- PhiLho

4

Perforce支持锁定，而且似乎对于某些无法合并的文件类型（例如二进制资源，如图像等），它需要此功能。然而，对于普通源文件，它不需要锁定，可以同时由多个用户打开进行编辑，然后合并回仓库。

我认为Perforce的“变更列表”系统非常好，这将多个文件的更改分组并将其视为一个单元。我相信你可以使用SVN做类似的事情，但这在开箱即用方面没有那么容易。

- unwind

3

实际上，SVN 的工作方式与 changelists 很相似。每个版本号是针对整个代码库的，因此如果您回滚到某个版本，您将回滚整个代码库。 - philsquared

2

我同意之前的Yuval所说的 - 我曾经使用过Perforce和svn，无论是在GUI还是命令行模式下，我都更喜欢svn。然而，当时我工作的公司从免费的cvs转向了Perforce。它的GUI更加华丽。我认为它的提交模型不同 - 它使用锁定，这可能更适合一些开发人员/经理。在商业环境中，拥有版本控制工具的支持人员也可能有所帮助。

我听说，在一些大型公司中，禁止在生产环境中使用开源代码，因为他们希望能够获得每行代码的支持。

- Yuval F

-1

一个Perforce服务器可以在客户端上读写任意文件，因此执行任意代码。 Perforce配置全部位于服务器端，因此服务器可以将客户机的整个硬盘视为存储库，并随心所欲地对其进行操作。

除非在SELinux沙箱中运行，否则永远不要运行Perforce。

记住：Perforce客户端是服务器的木偶。您必须使用操作系统的安全功能来防止它做出您不想让它做的事情。 始终将Perforce客户端视为敌对。

- Demi

客户端的代码执行没有服务器端控制。您有这个说法的证据吗？ - Br.Bill

可以。服务器控制存储库的末端，因此它可以告诉客户端覆盖任何文件。 - Demi

该操作由客户端控制。您可以完全控制它发生的时间。如果您不希望它发生，只需不同步客户端即可。 - Br.Bill

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Phil Nash · Accepted Answer

我使用Perforce、Clearcase、Sourcesafe、RCS、PVCS、CVS和Subversion已经多年了。最近，我也开始使用GIT。

基于我的经验，对于大部分商业环境来说，Perforce是最好的版本控制系统。尽管最初不如Subversion简单，但它有许多更强大的功能，尤其是分支和合并方面。默认“锁定”的方法通常更适合这种环境。

对于个人事务、小型协作项目、小型创业公司或开源项目，我发现在许多情况下Subversion更适合。它们有不同的方法和工作方式。你不能只是把它们排列在一条线上，然后断言哪一个最好。

话虽如此，我讨厌ClearCase。通常是从上面（即管理决策）强制使用ClearCase。

对于许多Subversion胜过Perforce的情况，现在很多人似乎更喜欢GIT、Bazaar、Mercurial等分布式系统。从我看到的GIT来看，他们可能是正确的，我相信其他人也会证实这一点。