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?)