java - Perforce值得吗？

Question

Closed. This question is opinion-based。它当前不接受答案。












想改善这个问题吗？更新问题，以便 editing this post用事实和引用来回答。

6年前关闭。



Improve this question




我的一位同事对PerForce的可能性感到非常兴奋(我们基本上需要有能力以逻辑方式对补丁和更改进行分组，并且获得SCM的本地支持会非常好)。我们目前使用CVS，并且对所有可能性开放。我们只有很少的开发人员使用纯Eclipse并使用ant脚本运行构建。

在跳入水中之前，我想听听其他人，他们出于技术原因可以说“好主意”或“坏主意”。我也想听听这对您的日常工作有多大干扰。

编辑2011年:仅作记录。我们迁移到git-决定性的因素是我们使用Eclipse，而eclipse.org则是git，因此最终可以期待非常好的IDE集成。我们还有些早-直到今年夏天Eclipse 3.7。今天，git在Eclipse中可以很好地工作。

EDIT 2015:事实证明，由于github和通用的IDE支持以及与Maven的结合，最终git成为了无可争议的赢家，最终使Java项目与IDE无关。

最佳答案

2011年11月更新:

出于多种原因(去中心化，私有(private)提交，分支， merge 等)，使用gitt作为forcefully advocated的Tilo显然是更好的选择。
我完全了解集中式和分散式VCS之间的差异，如“Describe your workflow of using version control (VCS or DVCS)”中所述。

但是，在大型企业中使用并不容易。
我知道。我在一家大型企业中介绍了Git:
我在“ Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development? ”中介绍了一般原因(同时仍然说DVCS是非常有效的选择)

但是我确实在“ Distributed Version Control Systems and the Enterprise - a Good mix? ”中详细介绍了在企业中安装Git的主要痛点。
实际上，我已经在最新的CodeKen 2011 (replacing the ex-DevDays 2011)中介绍了这些痛点。
该演示文稿被称为“Introducing DVCS in a big corporation”，并且这些推文 Eloquent Eloquent :

• Grundlefleck: My summary: one does not simply git into enterprise
• ben_sim: @VonC_ redefines pain at #codeken2011: recompiling git and and all its dependencies so you can use it on a production server in enterprise.

DVCS的诀窍是:您仍然需要一个“服务器”，这是所有开发人员获得其仓库的“加福”版本的集中位置。
在一家大公司中，那些相互关联的服务器是相互关联的……已经有许多其他服务正在运行，这意味着您不能仅在其上添加Git(在该服务器上没有正确的库)。
另外，您将需要自己的ssh和httpd，以便用户将其 push/pull 出该服务器。

实际上，我已经在 GitHub project compileEverything中自动完成了Git及其所有依赖项/相关服务的安装过程。

所以，是的，使用Git。
在客户端PC上，您可以在几分钟内安装并开始使用它!
但是在大型企业的服务器上？这不是那么容易。

记得2009年:

Windows上可能支持Git，但仍在进行中，

Git本身不包括“smart http”，这意味着ssh/clone和push操作具有身份验证的唯一协议(protocol)是ssh:说服用户生成和管理公钥/私钥是……至少可以说是有问题的。
即使请求效率很低，也可以使用Https进行 pull 和克隆。为了进行推送...安装涉及WebDAV，非常复杂。 Smart Http改变了这一切。

授权层很笨重(gitosis)，而gitolite才刚刚开始。
在大型企业中，您需要一个授权层。
没有任何用户可以访问任何存储库，其中一些存储库是非常 secret 的。

最初的答案，可以追溯到2009年:

在公司内部，在封闭的集中式环境中，Perforce当然是一个不错的选择。
它确实可以快速 checkout 您的工作区，并很好地管理变更集。
它支持“默认情况下锁定”，有助于查看谁在同一文件上工作。

但是， 您必须始终与P4服务器同步，并且应该具有适当的基础架构来支持它，包括备份和DRP方案:如果没有服务器，并且继续工作，例如删除文件，不会在后续更新中恢复。

我从使用它的团队中听到的主要提示(因为我只在该工具上执行了一些管理任务)是“ Inter-File Branching”的概念，起初有点令人困惑，但非常有用。

根据 Perforce with your IDE (here eclipse)和编辑器的集成级别，主要的侵入方面是确保工作空间保持同步。

其他有趣的链接供您阅读:

What are the advantages to Perforce?

What are the benefits of using Perforce instead of Subversion?

关于java - Perforce值得吗？ ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1346031/

上一篇：java - 我什么时候应该创建一个新的异常类

下一篇：java - 在 Tomcat 6 中重复出现 "PermGen"

相关文章：

java - CriteriaBuilder 没有方法 createCriteriaUpdate

javascript - 有没有办法使用 Javascript 将 html 与 RCP(E4) 应用程序交互？

java - 无法发布到 Tomcat 7 服务器 NullPointerException

git hook执行顺序

git - 从 Git 存储库中删除用户名

java - MarkLogic:将 Map-Object 从 Java 传递到 XQuery

java - 使用mapstruct映射不同类型列表的元素

java :direct gmail url

eclipse 中的 java.lang.ClassNotFoundException : org. springframework.web.context.ContextLoaderListener

Git diff 给了我一个致命的 : bad revision 'HEAD~1'

Answer 1

2011年11月更新:

出于多种原因(去中心化，私有(private)提交，分支， merge 等)，使用gitt作为forcefully advocated的Tilo显然是更好的选择。
我完全了解集中式和分散式VCS之间的差异，如“Describe your workflow of using version control (VCS or DVCS)”中所述。

但是，在大型企业中使用并不容易。
我知道。我在一家大型企业中介绍了Git:
我在“ Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development? ”中介绍了一般原因(同时仍然说DVCS是非常有效的选择)

但是我确实在“ Distributed Version Control Systems and the Enterprise - a Good mix? ”中详细介绍了在企业中安装Git的主要痛点。
实际上，我已经在最新的CodeKen 2011 (replacing the ex-DevDays 2011)中介绍了这些痛点。
该演示文稿被称为“Introducing DVCS in a big corporation”，并且这些推文 Eloquent Eloquent :

• Grundlefleck: My summary: one does not simply git into enterprise
• ben_sim: @VonC_ redefines pain at #codeken2011: recompiling git and and all its dependencies so you can use it on a production server in enterprise.

DVCS的诀窍是:您仍然需要一个“服务器”，这是所有开发人员获得其仓库的“加福”版本的集中位置。
在一家大公司中，那些相互关联的服务器是相互关联的……已经有许多其他服务正在运行，这意味着您不能仅在其上添加Git(在该服务器上没有正确的库)。
另外，您将需要自己的ssh和httpd，以便用户将其 push/pull 出该服务器。

实际上，我已经在 GitHub project compileEverything中自动完成了Git及其所有依赖项/相关服务的安装过程。

所以，是的，使用Git。
在客户端PC上，您可以在几分钟内安装并开始使用它!
但是在大型企业的服务器上？这不是那么容易。

记得2009年:

Windows上可能支持Git，但仍在进行中，

Git本身不包括“smart http”，这意味着ssh/clone和push操作具有身份验证的唯一协议(protocol)是ssh:说服用户生成和管理公钥/私钥是……至少可以说是有问题的。
即使请求效率很低，也可以使用Https进行 pull 和克隆。为了进行推送...安装涉及WebDAV，非常复杂。 Smart Http改变了这一切。

授权层很笨重(gitosis)，而gitolite才刚刚开始。
在大型企业中，您需要一个授权层。
没有任何用户可以访问任何存储库，其中一些存储库是非常 secret 的。

最初的答案，可以追溯到2009年:

在公司内部，在封闭的集中式环境中，Perforce当然是一个不错的选择。
它确实可以快速 checkout 您的工作区，并很好地管理变更集。
它支持“默认情况下锁定”，有助于查看谁在同一文件上工作。

但是， 您必须始终与P4服务器同步，并且应该具有适当的基础架构来支持它，包括备份和DRP方案:如果没有服务器，并且继续工作，例如删除文件，不会在后续更新中恢复。

我从使用它的团队中听到的主要提示(因为我只在该工具上执行了一些管理任务)是“ Inter-File Branching”的概念，起初有点令人困惑，但非常有用。

根据 Perforce with your IDE (here eclipse)和编辑器的集成级别，主要的侵入方面是确保工作空间保持同步。

其他有趣的链接供您阅读:

What are the advantages to Perforce?

What are the benefits of using Perforce instead of Subversion?