【问题标题】:What are the benefits of using Perforce instead of Subversion?使用 Perforce 而不是 Subversion 有什么好处?
【发布时间】:2010-09-14 12:28:16
【问题描述】:

我的团队已经使用 SVN 几年了。我们现在可以选择切换到 Perforce。

进行这样的转换有什么好处(和陷阱)?

【问题讨论】:

    标签: svn perforce


    【解决方案1】:

    我目前在不同的项目中同时使用这两种方法。

    • perforce 分支机制更胜一筹。
    • perforce 冲突解决工具更好。
    • 我真的很喜欢 perforce 强大的变更列表概念。
    • Perforce 似乎更快。
    • 设置和运行更容易。
    • 我们的一些成员非常喜欢用于 perforce 的 MS Office 插件,我在 Mac 上所以无法使用它。

    但是

    • SVN 客户端更好,尤其是 eclipse 插件。
    • Perforce 更贵。

    这些只是意见,所以也许这是一个糟糕的答案:)

    如果我已经在使用其中一种,我将很难切换,因为两者似乎都没有比另一种提供真正显着的好处,但切换的中断可能很大。

    更新:写这篇文章后,我已经完全转而使用 GIT 来用于个人和商业目的。任何一天我都会选择它而不是 SVN 或 Perforce。

    【讨论】:

    • 您能否详细说明为什么要使用 Perforce Eclipse 插件?我们目前正在评估该平台,但我找不到有关它的具体反馈...
    • 在我上次使用 SVN 时,Perforce 中的分支和记录合并要好得多。然而 hg 或 git 可能是当今分支/合并的最佳选择。
    • 自写这篇文章以来的 5 年里,我已经完全切换到 git 进行所有源代码控制。
    【解决方案2】:

    正确的分支和使分支成为命名空间的一部分是我在 Perforce 中看到的最大好处。合并很容易。我认为放弃 Subversion 没有任何不利之处。

    【讨论】:

    • 根据我的经验,在 Perforce 中合并与任何其他任务一样痛苦。
    【解决方案3】:
    • P4 在服务器上跟踪您的工作副本。这意味着
      1. 处理大型工作副本的速度要快得多。我曾经有一个大型 SVN 项目,一个简单的更新需要 15 分钟,因为它必须创建本地工作副本的树(数千个文件夹)。文件访问很慢。 P4 将有关工作副本的信息存储在数据库中,因此任何操作都几乎是即时的。
      2. 如果你乱搞文件而不告诉服务器,你就有麻烦了!您不能只删除一个文件 - 您必须使用 P4 客户端删除一个文件,以便服务器知道。请注意,如果您在本地删除文件,则不会在后续更新时再次下载它,因为服务器认为您已经拥有它!当很多这样的事情发生并且我最终严重不同步时,我通常不得不清理我的本地副本并再次下载它,这可能很耗时。您必须注意这一点。
    • Explorer shell 扩展客户端(想想 TortoiseSVN)很糟糕,完全无法使用。
    • 有两种 GUI 客户端应用程序可提供最佳功能:P4Win 和 P4V,其中 P4V 更新且更易于使用,但功能并不丰富。
    • 有 Visual Studio 和 Eclipse 插件,虽然没有很多高级功能,但效果相对较好。
    • 一般而言,P4 提供的功能比 SVN 少得多,而且有时完全令人困惑。
    • 工作副本定义很好而且很灵活。我相信 P4 在这里优于 SVN:您可以为工作副本文件夹定义掩码并创建各种奇异的树,因此您只需将您想要的内容下载到您想要的确切位置,而无需手动进行多次结帐。当我在服务器上有千兆字节的东西并且只想要它的特定子集时,这非常方便。我在类似的情况下使用了 SVN,但麻烦得多。
    • 在 P4 下的分支是……奇怪的。分支集和不同种类的分支以及令人困惑的 UI。很遗憾,我不记得太多细节了。

    除此之外,它非常标准。

    我建议您保留 SVN,除非您处理庞大的代码库或讨厌 .svn 文件夹乱扔文件系统。 SVN+TortoiseSVN 在大多数情况下更加舒适。

    【讨论】:

    • 重新分级第 2 点,P4V 有一个“协调离线工作...”选项,对此有很大帮助。此外,也许 Sander 最近没有使用图形客户端,但 P4V 比 P4Win 功能更丰富。 Perforce 正在放弃 P4Win 并专注于单一的跨平台图形客户端 P4V。
    • 是的,我的 P4 经验可以追溯到几年前。
    • 体重。 Tortoise 现在更好了,并且发现了大的工作副本错误 - 将很快修复(它仅适用于 Windows 和 NTFS 分区)。不过还没有修复。
    • 第 2 点不是问题。有一个entire article 涵盖了解决这个问题的所有方法。
    • 需要一整篇文章来介绍解决方法,这不就意味着这是一个很大的问题吗?
    【解决方案4】:

    我用过SVN,不是很多,只是为了试一试。我使用 Perforce 大约三年。我以为很好。客户服务非常出色,非常快地解决了一个错误,原来只是我很愚蠢,他们甚至实现了我建议的功能。

    其他一些必须使用它的开发人员,尤其是非开发人员发现学习使用它有点棘手,尤其是在定义客户端规范(服务器上的文件夹到本地文件夹的映射)时。

    我发现它可以非常快速地进出文件,而且非常可靠。我认为与我共事过的大多数开发人员都非常喜欢它,一旦我们习惯了它。不过,我们在切换之前使用的是 Visual Source Safe,所以几乎任何东西都比这更好。

    缺点是要花钱。我相信 SVN 是一个非常好的系统,因为 SVN 是免费的,我认为你必须有一个令人信服的理由来切换,尤其是 Perforce 确实需要一段时间来学习。如果 SVN 为你做这项工作,而你对此没有任何抱怨,我建议你留下来,以备不时之需!

    【讨论】:

      【解决方案5】:

      我都使用过,根据我的经验,如果你有一个庞大的团队和/或代码库,Perforce 会很有意义;否则我会选择 SVN - 它更容易设置和维护。

      【讨论】:

        【解决方案6】:

        您的团队评估过 Git 吗?它具有类似于 Perforce 中可用的功能,但是是免费的 (FOSS)。

        在与大型团队合作时,两者都是 SVN 的绝佳替代品。

        【讨论】:

        • 坦率地说,我倾向于同意这一点。就更传统的代码存储库而言,没有什么可以与 Perforce 相比。 Git 或 Mercurial 等分布式系统在代码管理问题上解决了一个类似但略有不同的变体,在我看来非常值得一看。
        【解决方案7】:

        在我看来,使用 subversion 而不是 Perforce 的主要好处是能够离线编辑内容并与您的同事同时进行。

        如果数据基础设施是松散结合的(有离线时间),svn 会摇滚。即使服务器无法访问,您也可以做很多事情。 Perforce 本质上需要一个始终可用的服务器连接。

        免责声明:我在 Perforce 上的信息很旧,在 2005-06 年使用了一段时间,然后才完全切换到 svn

        【讨论】:

        • 多人可以在 Perforce 中编辑同一个文件,并且已经能够做到这一点很长时间了。提交的第二个必须合并较早的更改。您可以更改文件,当您获得连接时,您可以执行“p4 diff -se | p4 -x - edit”。必要时同步/解析。
        • 当我需要离线工作时,我会继续编辑任何需要的文件。然后当我连接时,我打开所有内容进行编辑,然后执行“还原未更改的文件”,然后我神奇地得到了我在更改列表中触及的文件。
        • Perforce 在 2005-06 之前已经支持断开连接的工作方式。 Perforce 网站上有一个技术说明,描述了断开连接工作的推荐方法:kb.perforce.com/UserTasks/WorkingDisconnected
        • 文件很容易离线编辑。重新连接后,编辑您的文件并选择“协调离线工作...”。
        【解决方案8】:

        我在工作中使用 perforce,在家里使用 svn。

        perforce GUI 相当不错,但只有在你习惯了它之后。它肯定有一个学习曲线,当非程序员开始使用 perforce 时,通常需要一些时间才能获得概念。

        乌龟很棒,它非常易于使用。我的律师妻子使用它颠覆了她所有的文件;)

        分支很容易执行。事实上很容易,以至于人们没有太多理由分支。然后你整合,因​​为你分支了。它很容易成为你唯一要做的事情。

        Svn 集成在更多产品中。至少我使用的产品更多。这是一个很大的优势,因为如果您必须在开发环境之外使用任何一个,它们都会变得很笨重。

        每隔一段时间,我们就会遇到 perforce 问题,它认为您的本地副本是最新的,但事实并非如此。然后你必须强制同步,然后如果它仍然不好,删除你的本地文件并重新同步。 svn从来没有遇到过这样的问题。这实际上是一个大问题,因为您甚至都不知道自己正在处理旧副本。

        要考虑的另一件事是为什么要改变。如果您有一个可以运行的系统,并且每个人都熟悉并满意它,为什么要更换它?

        【讨论】:

        • 阿门。如果它没有坏,就不要修理它。
        【解决方案9】:

        在 Perforce 网站上,他们有一篇论文比较了两者: P4 vs SVN

        显然,鉴于来源,您必须意识到它强调了 Perforce 相对于 SVN 的优势,但它仍然是一本有用的读物​​。您永远不会知道,其中一个好处很可能是您的团队在您自己的独特情况下可以从中受益的杀手锏。

        我当然会推荐 Perforce,原因已经在其他答案中介绍过,但我无法与从未真正使用过的 SVN 进行比较。

        【讨论】:

          【解决方案10】:

          如果需要,您可以在 Perforce 中离线编辑内容。您的工作空间定义文件是只读的还是可写的,因此您可以将它们全部设为可写、修改,然后让 Perforce 找出需要签入的内容。

          最好将文件设为只读并检查您需要什么,以便其他人(和您自己)知道您已经/正在做什么。

          更适合您的系统取决于您的要求,如果您没有要求,则 Perforce 胜出。

          谁使用 Subversion? 小型非商业团队 廉价或小型商业团队

          谁使用 Perforce? 谷歌 索尼 三星 英伟达 赛门铁克

          【讨论】:

          • Subversion 客户端 (VisualSVN) 的公共客户列表可在visualsvn.com/company/customers上获得
          • 这根本不是真的。 SVN 正被大公司和庞大的存储库使用。 Google 将 GIT 用于其 Android 庞大的存储库,而不是 Perforce。
          【解决方案11】:

          我记得,随着席位数量的增加,Perforce 许可的成本会下降。因此,每个座位并不完全是 900 美元。它也是一个基于服务器的许可证;您为使用它的人类开发人员总数付费,而不是为使用它的每个机器客户端付费。因此,如果您是一家有 200 人的商店,那么 200 人的许可证让他们都可以使用 perforce,即使在家也是如此。

          【讨论】:

          • 即 200 个命名用户。这就是人们通常所说的“每个座位”。 200 个并发用户通常被称为“每台服务器”。 (Microsoft 的窗口服务器许可条款)
          【解决方案12】:

          在最近的版本中,Perforce 为 shelving changes 提供了一项新功能:

          搁置是在 Perforce 服务器上临时存储正在进行的工作而不提交更改列表的过程。当您需要在同一组文件上执行多项开发任务(例如中断更高优先级的工作、跨多个平台进行测试)或在将工作提交到软件仓库之前共享文件以进行代码审查时,搁置非常有用。

          这类似于 git 的分支模型,它可以让您在需要多任务时轻松地从一个本地分支切换到另一个。

          AFAIK,Subversion 没有类似的功能。

          More info on the Perforce blog.

          【讨论】:

          • 动机与git's stashing 更相似,我敢打赌他们的想法正是来自于此。
          • 我同意 p4 货架更像 git stashes。然而,p4 货架的想法早于 git,当 p4 客户让前 Perforce 员工在当时的 p4 之上实施类似的系统时。最近添加的 p4sandbox 和流与 git 本地分支有更多共同点。
          【解决方案13】:

          在我看来,在 SVN 和 Perforce 之间进行选择的原因#1成本

          小型存储库: SVN 做的很好,而且是免费的。

          Big 存储库:使用 SVN 是致命的:http://yoawsconsult.blogspot.com/2009/05/whenwhy-you-cant-afford-to-use.html。 Perforce 可以创建大型存储库,但您必须为此付费并了解它。

          【讨论】:

            【解决方案14】:

            能够通过 TortoiseSVN 从 exlorer 完成所有操作感觉非常舒服! 所以甚至安装了 P4 扩展。但它真的没有那么复杂!

            另一方面,P4 客户端提供了对服务器存储库的可访问视图,因此无需完全签出即可工作。在仅使用 TSVN 的 SVN 时代,这总是感觉有点麻烦。

            这么说我看不懂顶贴评论:

            • Explorer shell 扩展客户端(想想 TortoiseSVN)很糟糕,完全无法使用。

            对于 FOSS TortoiseSVN 来说简直太棒了! (即使图标的东西在每台机器上都有点讨厌和不同..)

            使用 TortoiseSVN 你:

            • 可以重新排列函数
              • 例如将“get lock..”放在前面
            • 实际上可以从资源管理器访问所有功能
            • 在 shell 菜单中有图标
            • 收到更新通知

            【讨论】:

            • 欢迎来到 Stack Overflow!请尝试用更客观的事实来支持您相当主观的意见。
            • @IngoKarkat:我希望那更好? ^ 另一方面:这不是一个传统的代码问题。在征求意见时,一些偏见是无法避免的。
            • “Explorer shell 扩展客户端(想想 TortoiseSVN)很糟糕,完全无法使用。”你误解了那句话。他没有说 TSVN 很烂,而是在谈论 Perforce Explorer 集成。
            【解决方案15】:

            Perforce 允许服务器拥有客户端。

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

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

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

            【讨论】:

            • 这没有回答问题。你有任何证据支持你的偏执狂吗?你说得好像“一个程序在技术上可以写入磁盘上的任何位置,如果它愿意的话”是非常罕见和不合理的。
            【解决方案16】:

            perforce 对子版本的一个缺点是 svn 中的导出命令。将某个版本的代码导出或下载到任何地方都更容易。您不需要为此创建工作区。但在 perforce 中,您只能将版本化代码获取到您的工作区。

            【讨论】:

              【解决方案17】:

              根据我的实践:

              • Perforce 还设计用于存储巨大的 blob 文件(如软件发行版),svn 将其所有数据存储为文本。 svn中无法有效存储这样的二进制数据

              • Perforce 支持有用的东西,例如“搁置更改”。用户要求 perforce 在 perforce 服务器中像“补丁”一样存储更改。如果作者要求,其他用户可以查看更改。 svn不支持

              • Svn 命令行格式更易于理解和记忆,适合日常使用

              • Svn 是免费的

              • 在“git”和“svn”中,您可以在从 repo 接收文件后直接通过编辑本地文件系统中的文件来编辑更改。实际上,处理文件的“正确”方法是将它们标记为您将要使用它们(p4 编辑)....理论上其他人可以查看它,实际上它不舒服

              • 本地系统中的 Perforce 客户端工作区准备需要比 svn 更多的时间,因为需要进行额外的配置

              【讨论】:

                猜你喜欢
                • 1970-01-01
                • 2022-08-03
                • 2016-05-26
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 2018-10-19
                • 2016-05-11
                • 1970-01-01
                相关资源
                最近更新 更多