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