Perforce值得吗？

2011年11月更新：

正如Tilo大力提倡的那样，使用Git显然是一个更好的选择，原因有很多（分散，私有提交，分支，合并等）。 我完全意识到集中式和分散式VCS之间的区别，如“描述使用版本控制（VCS或DVCS）的工作流程”中所述

但是，在大型 企业中 使用它 并不容易 。 我知道。我在一家大型企业中介绍了Git：
我在“我们最终可以在公司软件中最终迁移到DVCS吗？SVN仍然是开发的’必须’吗？ ”中暴露了一般原因（尽管仍然说DVCS是一个非常有效的选择）

但是我确实在“ 分布式版本控制系统和企业-好的组合？”中详细描述了在企业中安装Git的主要痛点。
实际上，我已经在最新的CodeKen2011中 提出了 这些痛点（取代了之前的DevDays2011）。
演讲被称为“ 在大公司中介绍DVCS
”，其推文雄辩地说：

*Grundlefleck：我的总结：不只是简单地混入企业
*ben_sim：@VonC_重新定义了＃preken2011的痛苦：重新编译git及其所有依赖项，以便可以在企业的生产服务器上使用它。

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

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

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

记得2009年：

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

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

• 授权层是笨重的（gitosis），而乙醇钠石才刚刚开始。在大型企业中 ，您 需要 一个授权层。 没有任何用户可以访问 任何 存储库，其中一些存储库是非常机密的。

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

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

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

我从使用它的团队中听到的主要抱怨（因为我只在该工具上执行了一些管理任务）是“
文件间分支 ”
的概念，起初有点令人困惑，但非常有用。

根据Perforce与您的IDE（此处为eclipse）和编辑器的集成程度，主要的侵入方面是确保工作区保持同步。