Perforce值得吗？
我的一位同事对PerForce的可能性感到兴奋（我们基本上需要在后勤上对补丁和更改进行分组，并且本机上的SCM支持非常好）。 我们目前使用CVS并对所有可能性开放。 我们只有少数使用纯Eclipse并使用ant脚本运行构建的开发人员。
在跳入水中之前，我想听听其他技术原因可以说“好主意”或“坏主意”的人。 我也想知道这在你的日常工作中有多么干扰。
编辑2011：仅供记录。 我们迁移到git – 决定性的因素是我们使用Eclipse和eclipse.org用于git，因此我们最终可以期待非常好的IDE集成。 我们有点早了 – 直到今年夏天的Eclipse 3.7。 今天git在Eclipse中非常好用。
编辑2015：事实certificate，git最终成为无可争议的赢家，这得益于github和一般的IDE支持，结合Maven最终使Java项目与IDE无关。
2011年11月更新：
正如Tilo 强有力地提倡的那样，使用Git显然是一个更好的选择，原因有很多（分散，私人提交，分支，合并……）。
我完全了解集中式和分散式VCS之间的区别，详见“ 描述使用版本控制（VCS或DVCS）的工作流程 ”。
但是，在大型企业中使用它并不容易 。
我知道。 我在一家大型企业中介绍了Git：
我揭露了“ 我们能否最终转向企业软件中的DVCS？SVN仍然是’必须’进行开发的一般原因吗？ ”（虽然仍然说DVCS是一个非常有效的选择）
但我真的详细介绍了在“ 分布式版本控制系统和企业 – 一个好的组合？ ”中在企业中安装Git的主要难点。
我实际上已经在最新的CodeKen 2011中 展示了这些痛点（取代了前DevDays 2011） 。
该演示文稿被称为“ 在大公司中引入DVCS ”，这些推文很有说服力：
- Grundlefleck ：我的总结：一个并不简单地融入企业
- ben_sim ：@VonC_重新定义了＃codeken2011的痛苦：重新编译git及其所有依赖项，以便您可以在企业的生产服务器上使用它。
使用DVCS的诀窍是：你仍然需要一个“ 服务器 ”，一个集中的地方让所有开发者获得他们的回购的“祝福”版本。
在一家大公司中，这些共享服务器是……共享的，还有很多其他服务已经运行，这意味着你不能只在它上面添加你的Git（你不会在该服务器上拥有正确的库）。
此外，您需要自己的ssh和httpd供您的用户推送/拉出该服务器。
我实际上已经在GitHub项目compileEverything中自动化了Git及其所有依赖项/相关服务的安装过程。
所以，是的，使用Git。
在客户端PC上，您可以在几分钟内安装并开始使用它！
但是在大型企业的服务器上？ 这并不容易。
记住2009年：
- Windows上的Git支持是可能的，但仍在进行中，
- Git本身没有包含“ 智能http ”，这意味着唯一具有拉/克隆和推送操作身份validation的协议是ssh：说服用户生成和管理公钥/私钥是至关重要的问题。
即使请求效率很低，也可以使用Https进行拉取和克隆。 对于推…设置涉及WebDAV并且很复杂。 Smart Http改变了这一切。 - 授权层是笨重的（ gitosis ），而gitolite几乎没有开始。
而且你需要在大企业中使用授权层。
没有任何用户可以访问任何存储库，一些所述存储库是非常机密的。
原始答案，早在2009年：
在公司内部，在封闭的集中式环境中，Perforce肯定是一个不错的选择。
它可以快速检查您的工作区，并很好地管理变更集。
它支持“默认锁定”，这有助于查看它在同一个文件上工作的人。
但是， 您必须始终与P4服务器同步 ，并且应该具有支持它的适当基础结构，包括备份和DRP方案：如果没有服务器，并且您继续工作，例如删除文件，则不会在连续更新时恢复。
我听到团队使用它的主要抱怨（因为我只对该工具执行了一些管理任务）是“ 文件间分支 ”的概念，起初有点令人困惑，但非常有用。
根据Perforce与IDE（此处为eclipse）和编辑器的集成级别，主要的入侵方面是确保工作区保持同步。
其他有趣的链接供您阅读：
- Perforce有哪些优势？
- 使用Perforce而不是Subversion有什么好处？
Perforce非常重，特别适合小团队。
我强烈考虑使用SVN或GIT，以获得良好的，良好支持的VCS，然后使用可用的工具和最佳实践（均可从您友好的本地Internet免费获得）来支持您需要的function。
例如，使用SVN，您可以设置帮助组更改的“bugtraq”属性。 我们只需在每个错误修正提交中输入错误ID（您甚至可以在签入GUI表单中为它获取一个很好的输入字段）然后仍然将mutli-commit错误修正分组。
关于此function的合理博客文章： http ： //markphip.blogspot.com/2007/01/integrating-subversion-with-your-issue.html
同样，它得到了工具的良好支持，使得它成为我们几个团队的一个不错的调用。
我最近听说过关于GIT的更好的事情（哎呀，spring的家伙正在使用它，而且经常会说很多）但我们自己也在颠覆，所以我可以评论一下。
在工作中，我们曾使用Visual SourceSafe多年，然后在去年切换到Perforce。 它绝对是昂贵的，我们还有一个在“构建”用户下运行的Ant构建脚本，它被视为一个有用的用户，有点烧伤。 该公司支付了为期2天的培训研讨会，所以这里的开发人员很快就加快了速度，但是仍然存在关于如何做foo等的问题（我是支持其他用户的小组的一部分）关于Perforce问题 – 主要是因为Visual Studio的工作方式，而不是真正的Perforce本身。
在使用Perforce方面，我认为最大的区别在于Perforce概念化跟踪变更的整个任务。 例如，subversion保存一个名为.svn的目录来保存有关文件的元数据; 使用p4，p4服务器本身会保留您拥有的文件列表。 这似乎是问题的最大来源 – 有人告诉p4服务器获取项目的最新文件，然后手动删除一些东西。 当他/她再次向p4服务器询问最新消息时，p4服务器认为他/她已经拥有它，因此它不会更新。 一旦人们“得到”这个，就会变得更加容易。 您只需要告诉服务器“从工作区中删除”然后再次获取它。
我们混合使用MS Visual Studio用户以及Eclipse和IntelliJ，并且p4插件支持所有这些工作非常好。 入住/退房和获取最新的日常工作也不例外。 我们大多使用基本function，即便如此，它似乎是对Visual SafeSafe的改进（然后再次，从我看到有时在网上看到的咆哮，可能任何东西都是对Visual SourceSafe的改进）。 只要同时拥有多个开放式变更清单，我们就可以为我们的工作方式提供很多灵活性。 似乎Perforce插件设置更喜欢静音检查，许多用户立即注意到，但我非常喜欢它，我认为总体而言，这是对生产力的改进。 IDE将突出显示不同颜色的文件名，因此您可以查看是否已修改某些内容 – 并且p4更改列表始终显示您已检出的内容。
当多个用户签入文件更改时合并更改非常简单。 差异工具并不是非常壮观，但我们可以很好地比较冲突，只需点击我们想要的。 我应该注意gui工具非常好。 这里的大多数开发人员都不使用p4v客户端，但有些人和我一直使用它。 我提到gui工具很棒吗？ 您可以查看所有提交的更改列表，查看文件历史记录，将一个修订版拖放到任何其他修订版本上并获得即时差异，查看显示分支历史记录的修订图，查看“延时”视图文件的修订版（非常简洁的function – 在顶部来回拖动滑块，并观察每个版本的文件内容更新）。
我们只完成了一些代码分支，所以我们还没有很好的经验。 到目前为止，它非常简单，合并更改也很容易。 作为培训课程的一部分，每个人都获得了Perforce技术副总裁或其他人编写的“实用Perforce”。 关于处理代码行和分支的不同方法，有很多内容。 我认为当我们使用SourceSafe时，我们在它能做的事情上是如此有限，我们只能以某种方式思考 – Perforce更加灵活，突然之间实际上可能有不同的哲学关于何时/如何/为什么应该设置代码行在这方面，我们仍在尝试分支和整合（合并）方面的许多事情。
PS双用户设置不需要许可证，仅限制您使用5个工作区。 您可以在没有时间限制的情况下评估它。 他们还为开源项目提供免费（但不受支持）的许可。
我们正在使用它，它肯定有很多“好东西”推荐它。 你必须习惯它，并考虑“在Perforce中”。
通常，您的软件仓库具有自己的目录结构，每个用户都有映射，用于定义这些文件/目录在本地放置的位置。 例如，这使得使用不同版本的相同部件替换层次结构的整个部分变得相对容易，因此管理产品的不同版本和分支更加容易。
它还支持管理变更集，并以primefaces方式检查变更集。 当您试图找出其他代码中的某个签入影响的内容而不仅仅是您当前正在查看的文件时，这确实有用。
我们在Perforce之前使用Vault，并且所有过渡都非常顺利，没有太多的生产力损失。 🙂
我在工作中使用Perforce，之前在上一份工作中使用过CVS。 在初始学习曲线之后，使用该CVS要好得多。 （从头开始学习可能比CVS更容易，但我没有这方面的经验。）如果有人需要集中的源代码控制系统，我会建议Perforce，只要他们有资源许可它。
另一方面，我最近一直在研究一些分布式源代码控制系统（特别是git，Mercurial和Bazaar）。 它们具有许多看起来非常有趣的function，尤其是不需要持续的服务器连接。 此外，您可以将系统设置为具有“主”服务器，即使使用分布式系统也是如此。 因此，我建议首先查看其中一个，看看它们是否符合您的需求。
这个问题在性质上类似于Ant是否优于Maven或C＃优于Java。 人们的意见会受到战斗伤痕的影响，大多数人只有1到3个SCM工具的艰苦实用经验，所以不能给你一个平衡的意见。
我将首先与团队坐下来，列出CVS在function，性能和集成方面的缺点。 然后查看各种SCM工具，了解哪些适合您的需求。
尝试Subversion，Git，Mercurial或其他一些开源SCM会有一段时间吗？ 如果事实certificate它们不适合用途，那么至少它会让你知道在评估Perforce时要寻找什么。
Perforce的大多数好处也可以在Subversion中使用。 Subversion也更易于管理，并且没有必要保持与服务器的连接。
但是，我发现p4语法更容易使用，输出比svn更不含神秘。
我曾经使用过svn，cvs，vss，现在我正在使用perforce。 我使用baazar为我的个人项目，我尝试了git和mercurial。
我不建议你使用perforce，当然我也不建议你使用VSS。 与之合作是不安全，不可靠和不切实际的。 它的模型比svn，cvs，git等等更加扭曲。使用脚本也更加困难（因为你必须处理视图，客户端和其他系统变量）。
我建议你使用任何常规问题跟踪器。 您可以根据需要通过svn钩子自定义….在某些情况下，分发（git，mercurial，baazar）会很有趣，但是如果你还没有意见，那么你应该从svn开始。
好吧，那是我的观点当然……
Perforce既昂贵又不值得信赖。 它不能可靠地将正确的文件放在工作区中，有时会留下过时的版本。
perforce有很多东西是正确的，它可以比其他类似的解决方案更简单地处理非常大的二进制文件，但是这个问题足以让我建议不要在任何项目中使用它。
这一年是2011年
最简洁的答案是不！ 用Git！
过去，我在大公司（约2000人）中使用和管理CVS和Perforce已有好几年了。 我强烈建议任何时候使用Git over Perforce – 即使在企业环境中也是如此。 来自CVS，花了一些时间来理解做事的“Git方式”，但经过一段时间的使用后，很明显它的范式是多么优越。
像Sun Microsystems这样的大公司在2006年已经certificate了如何从集中式版本控制系统（CVS）转换到分布式版本控制系统（Mercurial）是有益的。
恕我直言Perforce基本上是一个经过修改的CVS，它被混淆并且复杂到使用它非常痛苦（并且很慢），并且你需要他们服务部门的帮助来完成工作。 它的设计使您在某一点或另一点需要他们的服务部门。（例如，当您尝试自动化周围的流程时）。 哦，许可证真的很贵！ 你为什么要使用这样的产品？ Perforce真的很适合它的管理员的工作安全性;-)
另一方面，Git是一个非集中式版本控制系统（VCS），它更适合开发人员的工作方式。 他们可以轻松地创建本地（丢弃）分支，用于function开发或错误修复，并在版本控制下将该代码保存在本地，并在以后需要时将其合并回公共存储库。 他们的临时分支机构不会污染项目。 如果有一个守门员，他们可以要求他们提取更改，或者如果有公共存储库，他们可以轻松地将其本地代码更改合并到其中。 合并或创建Diff，对于开发人员来说是非常频繁的操作（！），并且对Git来说非常快。 最重要的是，Git非常可靠，并且很容易发现磁盘损坏（因为它使用SHA1校验和）。
LINUX内核项目非常成功地使用Git！ 看看这个演讲，跳到16分25秒，Linux Torvalds提到Perforce： http ：//vodpod.com/watch/65074-tech-talk-linus-torvalds-on-git
答案很长的答案是：
软件也在不断发展，版本控制系统（VCS）也在不断发展。 自Perforce创建以来，很多事情都是以艰难的方式学到的。 1990年，版本控制系统的口号是拥有一个集中系统，处理公司内部的所有软件项目。 所有源代码和分支都位于一个中心位置……事实certificate，管理不仅困难且昂贵，而且还显示出一些巨大的固有缺点：
-
对VCS的一个简单要求是，如果您将一个文件放在存储库中，那么您将获得具有相同权限的相同文件 – 不加改变。 对于Perforce或CVS，情况并非如此。
-
将所有类型的分离软件项目集中在一个集中式VCS中并不是一个好主意
-
集中式版本控制系统中的分支通常是一个巨大的痛苦
- 创建新的分支很慢，需要和管理，并锁定版本控制系统（在Perforce或CVS的情况下：几分钟到一个小时！抱歉，你无法办理登机手续，我们正在创建一个新的分支… ）
- 一般来说，分支是全局可见的，这意味着你需要良好的命名约定，并且人们通常不愿意创建新的分支（以防止“支气管炎”） – 但结果总是一堆乱七八糟的分支。
-
本地开发是在版本控制系统之外完成的，代码只有在“稳定”之后才会被检入（这本身就会使首先出现VCS失效，因为如果本地磁盘崩溃，开发人员可能会失去几天的工作）
-
开发人员不能只为新function开发创建本地分支，并且不会在集中式VCS中显示它
-
当公司试图在几个地理位置使用他们的“集中式”VCS时，通常会出现问题（这肯定会导致Perforce出现问题和痛苦）
-
集中式VCS的管理员成为瓶颈
-
集中模型意味着性能受到打击，甚至做一个像diff这样的简单事情，因为一切都意味着网络操作
-
你无法离线工作
-
人们需要提交访问代码的访问权限
-
与Perforce或CVS合并是繁琐，耗时且昂贵的！ ……以及开发人员必须做的非常频繁的工作！
听听linus： http ： //vodpod.com/watch/65074-tech-talk-linus-torvalds-on-git
Eclipse的P4Eclipse Perforce插件有一个Team – > Create Patch选项，如下所述：
http://www.perforce.com/perforce/doc.current/manuals/p4eclipse/topics/patch.html
如果你想把脚趾放在水中，Perforce有一个免费的20用户版，你可以通过免费支持测试：
http://www.perforce.com/downloads/Perforce/20-User
要通过Perforce中的命令行创建补丁，您可以运行’p4 diff2 -u’来生成补丁兼容输出，但必须提交更改。
要通过P4V在Perforce中创建补丁，您可以将挂起的更改列表搁置在一个工作区中，然后在另一个工作区中取消搁置。 这是一篇显示搁置行动的博文：
http://www.perforce.com/blog/130304/light-code-review-shelving
无论你决定什么，希望你能找到你想要的东西。