Perforce 有什么优势？答案

【问题标题】：What are the advantages to Perforce?Perforce 有什么优势？
【发布时间】：2010-09-19 22:59:49
【问题描述】：

Perforce 有什么好处？

我很想了解 Perforce 如何在特定情况下比 Subversion 更好地工作。

如果你同时使用 Perforce 和 Subversion 并且你不相信有任何优势，或者认为 svn 比 Perforce 有优势，我也想知道为什么。

【问题讨论】：

Perforce 摇滚。我使用过 SVN、视觉源安全和其他系统。我也使用 perforce 好几年了。我不会在其他任何东西上运行商业项目。

标签： svn version-control perforce

【解决方案1】：

就个人而言，我鄙视强制执行。它的用户界面很糟糕，很复杂，而且根本不直观。它经常出现故障和崩溃。

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

当然这一切都是从用户的角度出发，可能 SCM 有不同的视角

【讨论】：

我完全不同意。在过去的 6 年里，我一直在使用 Perforce。崩溃很少，也许是 5 年前，但今天的 Perforce 坚如磐石。你必须学习的 UI，或者你只是使用更新的 P4V，它有一个更“windows”的顺从 UI。
我会向您指出 P4WSAD（perforce-eclipse 集成），它是错误的。无论如何，用户体验是完全客观的，因此我的回答开头是“个人”。
我认为根据可选插件的优点（或缺乏）来判断整个 SCM 是不公平的。我每天都使用 Perforce，使用 Java 但没有插件。我只是在 Eclipse 之外处理源代码控制。很简单。
perforce 客户端（Windows）从未在我身上崩溃过。
是的，Eclipse 与许多东西的集成简直是马车。根据这个特定的用例来判断工具是不公平的。

【解决方案2】：

我同意之前的 Yuval - 在 GUI 和命令行模式下使用过 Perforce 和 svn，我更喜欢 svn。然而，我当时工作的公司从它使用的免费 cvs 切换到了 Perforce。它的 GUI 更加华丽。我认为它的提交模型是不同的——它使用锁定，这可能比某些开发人员/经理更可取。在商业环境中，为您的版本控制工具配备支持人员也可能会有所帮助。听说有些大公司禁止在生产环境中使用开源代码，因为他们希望每一行代码都能得到支持。

【讨论】：

【解决方案3】：

Perforce 支持锁定，并且对于某些无法合并的文件类型（二进制资源、思考图像等）似乎需要它。但是，它不需要锁定普通源文件，这些源文件可以同时被多个用户打开进行编辑，然后合并回软件仓库。

我发现 Perforce 的系统带有“更改列表”，该组更改为多个文件并将它们视为一个单元，很好。我相信你可以用 SVN 做一些类似的事情，但它并不是那么容易开箱即用。

【讨论】：

实际上 SVN 的工作方式与变更列表非常相似。每个版本号都是存储库范围内的，因此如果您回滚到某个版本，则会回滚整个存储库。

【解决方案4】：

Perforce 的模型与 svn 有点不同。每个文件始终锁定在您的工作副本中，您必须声明强制您开始编辑它。这有例如优点是您始终可以立即查看还有谁在处理文件。

总而言之，与其他 SCM 的差异并不是很大。您在很多地方都会遇到 Perforce，因为它曾经是少数（如果不是唯一的）部分体面的 SCM 之一，可以在 Windows 和 Mac 上运行。

如果我没记错的话，您可以在有限数量的客户中免费使用它，这样您就可以毫不费力地试用它...

【讨论】：

不强制锁定，仅在二进制文件上（不能合并）。不过，几个人可以一起处理同一个 ASCII（例如源代码）文件，然后将它们合并。
Perforce 有一个免费的 2 开发者专用许可证。
也很容易从 Perforce 获得临时来为您的团队测试它。只需致电询问，即可免费获得所需数量的许可证，有效期为 30 或 60 天。
您可以将 Perforce 工作区配置为在编辑前不需要签出。它是工作空间规范的一部分。

【解决方案5】：

我与 Perforce 以及 Clearcase、Sourcesafe、RCS、PVCS、CVS 和 Subversion 合作多年。最近我也开始使用 GIT。

根据这次经验，我认为对于大多数用途而言，Perforce 是商业环境中最好的版本控制系统。虽然最初不像 Subversion 那样简单，但它具有许多更强大的功能，尤其是在分支和合并方面。 “默认锁定”的方式一般更适合这种环境。

对于个人资料、小型协作项目、小型初创企业或开源项目，我发现 Subversion 在许多情况下更适合。他们有不同的方法，不同的工作方式。你不能只把它们按比例排列，然后说哪个最好。

也就是说我讨厌 ClearCase。 ClearCase 通常是从上面强制下来的（即管理决策）。

对于 Subversion 胜过 Perforce 的许多情况，如今许多人似乎更喜欢 GIT、Bazaar、Mercurial 等分布式系统。从我对 GIT 的了解来看，他们很可能是对的，我相信其他海报也会证明这一点。

【讨论】：

Phil - 您完全可以对 Clearcase 发表自己的看法，但我想知道您为什么“讨厌”它？是什么让你如此愤怒？ :)
这是我大多数同事的共同观点 :-) ClearCase 很重、很慢而且很复杂。它在批量签入时特别糟糕，并且没有将同时签入的文件关联在一起的概念（如 Perforce 的更改列表）。我想说更多，但我没有字符！
Clearcase 是企业化的、不直观的，并且没有原子签入。我不得不偶尔使用它，而且我每次都被一些愚蠢的东西绊倒。
ClearCase 确实允许使用 UCM 进行原子签入。

【解决方案6】：

您可能会在 What are the benefits of using Perforce instead of Subversion? 中找到提示（就在您的 Perforce 标签之后...）。

我们在工作中使用 Perforce，虽然我对各种 SCM 软件几乎没有经验，但我发现这款软件做得很好，具有良好的 GUI（在 Windows 上）、良好的命令行支持、许多不错的功能......可能需要一段时间来习惯它的逻辑，但我认为对于大多数 SCM 来说可能都是如此。

【讨论】：

【解决方案7】：

Perforce 的一大卖点是速度。服务器跟踪客户端上文件的状态；因此，诸如“获取仓库的最新状态”之类的操作是微不足道的——服务器已经知道你有什么文件，它可以将最少量的信息发回给你。

这个优点也带来了一个缺点，如果你在本地编辑文件而不先检查它们，在本地移动文件而不执行集成，或者在本地删除文件，服务器和客户端可能会不同步。

由于 Perforce 服务器只向客户端发送最少的数据，因此 Perforce 在慢速链接上表现良好，例如美国的客户端访问伦敦的仓库的情况。话虽如此，Perforce 协议相对“健谈”，因此很容易因拥塞的链接而减速。

【讨论】：

我同意您评论的缺点，特别是如果您由于某种原因无法连接到服务器。不过，让 Perforce 解决这个问题很容易：stackoverflow.com/questions/266771/…
是的，它被称为“强制重新同步”。
这种不利的想法来自不了解 VCS 的人。本地文件是 RO，直到您将其签出。做错事需要真正的努力。而且，即使错误的事情发生了，也不会发生两次......
“Perforce 的一大卖点是速度”...嗯...目前我在一个大集成中，它已经合并了 5 个小时...
@Calmarius 升级服务器上的磁盘。 Perforce 网络流量被设计为快速，但它会吃掉它可以获得的所有服务器资源。特别是，集成受益于快速 I/O。

【解决方案8】：

我每天在工作中使用 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 的难度是其他工具的 10 倍。
如果您开始使用它并通过脚本将其与您的流程联系起来，您可能会因此而死，因为一切都是以 perforce 方式和 perforce 方式完成的 :(
图像很容易关闭 p4 服务器：只需在项目的根目录上进行同步即可。在我工作的地方，这是不允许的，因为它会导致发球失败！有一个监视脚本正在监视 perforce 服务器进程，如果其中一个进程占用 x GB 的 RAM，它会杀死它并向您发送通知。是的，在客户端执行一个简单的命令可以在 5-10 秒内在服务器上创建一个 3GB 的进程。

【讨论】：

我几乎不同意你在这里所做的每一个陈述。文件编码是可配置的，如果你错误地设置了 Perforce，那不是他们的错。脚本很棒，而且支持这么多语言（Java/Python/Ruby/.NET 等），入门门槛很低。 SCM 的脚本几乎总是为所选软件定制的，我想不出一个不是这种情况的案例。我真的无法评论关闭服务器，因为我从未见过这种情况发生，甚至在英国和澳大利亚之间同步整个仓库。
我尊重您的意见，但不要忘记“整个仓库”可能因一家公司而异。我有很多文件（6 位数！）和超过 30GB 的数据在一个仓库中。
@sorin 不确定 Perforce 在您的公司是如何设置的，但我们在我们的仓库中托管了超过 7 位数的文件，而您所说的永远不会发生。有些东西告诉我你的配置有问题。

【解决方案9】：

Perforce 服务器可以在客户端读取和写入任意文件，从而执行任意代码。 Perforce 配置都是服务器端的，因此服务器可以简单地处理客户端的整个硬盘客户的计算机作为存储库，然后为所欲为。

除非在 SELinux 沙箱中，否则切勿运行 Perforce。

记住：Perforce 客户端是服务器的傀儡。您必须使用操作系统的安全功能来防止它做一些您不希望它做的事情。 始终将 Perforce 客户端视为敌对。

【讨论】：

客户端上的代码执行没有服务器端控制。你有这个说法的证据吗？
是的。服务器控制存储库的结束位置，因此它可以告诉客户端覆盖任何文件。
该动作由客户端控制。您可以 100% 控制它何时发生。如果您不希望它发生，您可以不同步客户端。