I've seen some people love and some loathe Perforce. As users or administrators with experience with other version control systems (free cookie to the ones with DVCS experience [git, Mercurial]), what is the main reason/feature that makes you love Perforce over other version control systems?

Edit: No, I don't sell Perforce... this is just part of my ongoing research to pitch DVCS at my company (see my question history)

closed as not constructive by Robert Harvey, dasblinkenlight, EL Yusubov, mattnz, Thomas Owens Oct 18 '12 at 2:06

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • There are reasons to love Perforce? I mean, outside of the fact you are a perforce salesman . . . – Wyatt Barnett Oct 18 '12 at 0:03
  • Are you deliberately trying to sound like a shill? – Robert Harvey Oct 18 '12 at 0:05
  • @WyattBarnett Maybe that you didn't know version control existed :) – dukeofgaming Oct 18 '12 at 0:06
  • @RobertHarvey I'm trying to hide the fact that I loathe it, if you see my question history you will know that I'm pitching DVCS at my company, this is only part of my research – dukeofgaming Oct 18 '12 at 0:08
  • 1
    @RobertHarvey No problem, your reaction on how someone asking why Perforce could be better or even why could one love it was actually hilarious to me – dukeofgaming Oct 18 '12 at 0:11

I have used perforce "in anger" i.e. on a project; it is very good for situations in which your source tree is extremely large- dozens to hundreds of gigabytes of source code in multiple languages, binaries (which should not have been checked in), etc.

Similar to subversion, it lets you check out only a part of a repository at a time. Unlike subversion, it has support for checking out multiple branches of a source tree, at different levels, in parallel. This is important if you have a legacy app which at one time has had different teams working on the same codebase and tests, and following different directory conventions.

After an initial period of adjustment (under a week, on and off as needed) I understood Perforce and its use cases in my scenario.

I was on the project for less than four months; the project itself was over a decade old.

I cannot think of a reasonable way for the project that I was on to move off of perforce; splitting the repository into submodules would bring all work to a halt, which is in general economically infeasible for a large company. However, individual teams can use git-to-subversion tools which help development.

Jenkins (a continuous integration tool) has plugins which fully support using perforce, so it is not incompatible with agile practices.

Perforce is very definitely an 'enterprise' tool in that most small teams don't need it unless they're working with a poorly designed file tree or with many large binary files (maybe video game developers or graphic designers would have this need, if they're sharing their version-controlled repository of binaries with one or several code projects?)

Not the answer you're looking for? Browse other questions tagged or ask your own question.