The year is 2011
The short answer is: No! Use Git!
In the past I have used and administered CVS and Perforce in large companies (~2000 people) for several years.
I would strongly suggest to use Git over Perforce any day -- even in a corporate environment.
Coming from CVS, it took some time to understand the "Git way" of doing things, but after a short time using it it becomes clear how superior it's paradigm is.
Big companies like Sun Microsystems have demonstrated back in 2006 how switching from centralized version control systems (CVS) to distributed version control systems (Mercurial) is beneficial.
IMHO Perforce is basically a modified CVS, which was obfuscated and complicated to the point that it is extremely painful (and slow) to use, and you will need help from their service department to get things done. It's designed so you will need their service department at one point or the other.. (e.g. when you try to automate processes around it). Oh, and the licenses are really expensive! Why would you want to use such a product? Perforce is really good for job-security of it's administrators though ;-)
Git on the other hand, is a de-centralized Version Control System (VCS), which is much more suitable for how developers work. They can easily create local (throw-away) branches, for feature development or bug-fixing, and keep that code locally under version control, and merge it back to a public repository later if needed. Their temporary branches don't pollute the project. If there is a gate-keeper, they can ask them to pull their changes, or if there is a public repository, they can easily merge their local code changes into it. Merging or creating a Diff , are very frequent operation for developers(!), and are super-fast with Git. On top of that Git is very reliable and will find disk corruptions easily (because it uses SHA1 check-sums).
The LINUX kernel project is using Git very successfully!
Check out this talk, and skip to minutes 16..25 where Linux Torvalds mentions Perforce:
http://vodpod.com/watch/65074-tech-talk-linus-torvalds-on-git
The long answer is:
Software evolves, so do Version Control Systems (VCS). A lot of things were learned the hard way since the days when Perforce was created. In 1990 the mantra of version control systems was to have a centralized system, which handles all the software projects inside a company. All your source code and branches in one central place... This has proven to be not only difficult and expensive to administer, but has also shown some huge inherent drawbacks:
a simple requirement for a VCS is that if you put a file in the repository, that you get the same file with the same permissions back -- unaltered. With Perforce or CVS this is not the case.
having all kind of disjunct software projects stuffed together in one centralized VCS is really not a good idea
branching in centralized version control systems is usually a huge pain
- creating new branches is slow, requires and admin, and locks up the version control system (in case of Perforce or CVS: several minutes to an hour! sorry you can't check-in, we're creating a new branch...)
- in general branches are globally visible, which means that you need good naming conventions,
and that people are usually reluctant to create new branches (to prevent "branchitis") -- still, the result is always a mess of branches.
local development is done outside the version control system, and code gets checked in only after it's "stable"
(this by itself invalidates having a VCS in the first place, because the developers could lose several days
of work if their local disk crashes)
developers can't just make a local branch for a new feature development, and have it not show up in the centralized VCS
problems typically arise when a company tries to use their "centralized" VCS in several geographical locations
(this definitely causes problems and pain with Perforce)
the administrator of a centralized VCS becomes the bottleneck
the centralized model means a performance hit, even to do a simple thing like a diff, because everything implies a network operation
you can not work offline
people need to have commit-access to check-in code
merging with Perforce or CVS is tedious, time-consuming, and therefore expensive! ... and a very frequent job which developers have to do!
