Is Perforce worth it? [closed]

Answer 1

Update November 2011:

Using Git, as forcefully advocated by Tilo, is obviously a better choice for a number of reasons (decentralization, private commits, branching, merging, ...).
I am fully aware of the differences between Centralized and Decentralized VCS, as detailed in "Describe your workflow of using version control (VCS or DVCS)".

However, using it in an large enterprise is not easy.
I know. I introduced Git in a large enterprise:
I exposed the general reasons in "Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?" (while still saying that DVCS is a very valid choice)

But I really detailed the major pain points in installing Git in enterprise in "Distributed Version Control Systems and the Enterprise - a Good mix?".
I have actually presented those pain points in the latest CodeKen 2011 (replacing the ex-DevDays 2011).
The presentation was called "Introducing DVCS in a big corporation", and the tweets were eloquent:

• Grundlefleck: My summary: one does not simply git into enterprise
• ben_sim: @VonC_ redefines pain at #codeken2011: recompiling git and and all its dependencies so you can use it on a production server in enterprise.

The trick with a DVCS is: you still need a "server", a centralized place for all the developers to get a "blessed" version of their repo.
And in a large corporation, those mutualized server are... mutualized, there are a lot of other services already running, which means you cannot just add your Git on it (you won't have the right libraries on that server).
Plus, you will need your own ssh and httpd for your user to push/pull to/from that server.

I have actually automated the installation process for Git and all its dependencies/related services in the GitHub project compileEverything.

So yes, use Git.
On a client PC, you can install and start using it in minutes!
But on a server of a large enterprise? This isn't so easy.

Remember 2009:

• Git support on Windows was possible, but still in progress,
• Git itself didn't include "smart http", which meant the only protocol with authentication for pull/clone and push operations was ssh: convincing users to generate and manage public/private keys is... problematic to say the least.
  Https was possible for pull and clone, even if the request was quite inefficient. For push... the setup involved WebDAV and was complex. Smart Http changed all that.
• authorization layers was clunky (gitosis), and gitolite was barely starting.
  And you need an authorization layer in big enterprise.
  Not any user can access to any repository, some of said repositories are quite confidential.

---

Original answer, back in 2009:

Within a corporation, in a closed centralized environment, Perforce is certainly a good option.
It does checkout your workspace fast, and manage changeset nicely.
It supports "locking by default" which help to see who it working on the same file.

However, you must be in sync with the P4 server at all time, and should have the proper infrastructure to support it, including backup and DRP scenarios: if no server, and you go on working, deleting a file for instance, it will not be restored on successive updates.

The main complaint I hear from the teams using it (since I only do a bit of administration tasks on the tool) is the notion of "Inter-File Branching", a bit confusing at first, but very useful.

Depending on the level of integration of Perforce with your IDE (here eclipse) and editors, the main intrusive aspect will be to make sure to keep your workspace in sync.

Other interesting links for you to read:

• What are the advantages to Perforce?
• What are the benefits of using Perforce instead of Subversion?

Answer 2

I've worked with svn, cvs, vss, and now I'm working with perforce. I use to work with baazar for my personal projects, and I have tried git and mercurial.

I don't recommend you perforce at all, and of course i don't recommend you VSS either. It's insecure, unreliable and impractical to work with. It's model it's much more twisted than svn, cvs, git, .. etc .It is also more difficult to use with scripts (as you have to deal with views, clients, and other system variables).

I would recommend you svn with any regular issue tracker. You can customize it throught svn hooks as desired.... In some cases it would be interesting to go distributed (git, mercurial, baazar), but if you don't have an opinion yet, you should start with svn ..

well, thats my opinion of course...

Answer 3

This question is similar in nature to whether Ant is better than Maven or C# better than Java. People's opinions will be influenced by their battle scars, and most people only have hard, useful experience of 1 to 3 SCM tools so can't give you a balanced opinion.

I would start by sitting down with the team and listing the shortcomings of CVS in terms of features, performance and integrations. Then look at the various SCM tools to see which fit your needs.

Would it hurt to try Subversion, Git, Mercurial, or one of the other open source SCMs for a while? If it turns out they aren't fit for purpose, at least it will give you an idea of what to look for when evaluating Perforce.

Answer 4

Perforce is both expensive and untrustworthy. It doesn't reliably place the correct files in a workspace, leaving with stale versions at times.

There's a lot of things that perforce gets right, and it can handle very very large binary files more simply than other comparable solutions, but that one problem is enough to make me recommend against using it for any project.

Answer 5

We're using it, and it definitely has a lot of "goodies" to recommend it. You do have to get used to it a little and think "in Perforce", though.

In general, you have the depot with its own directory structure, and each user has mappings that define where those files/directories will be placed locally. This makes it relatively easy to replace whole parts of the hierarchy with the same parts from a different version, for example, so managing different versions and branches of your product is easier.

It also has support for managing change sets, and checking them in atomically. This can really help when you're trying to figure out what else a certain checkin affected in the rest of the code and not just the file you're currently looking at.

We were using Vault before Perforce, and all-in-all the transition was very smooth without too much lost productivity. :)

Answer 6

I use Perforce at work, having previously used CVS at my last job. After the initial learning curve, it is much better to use that CVS. (It's probably easier to learn from scratch than CVS, but I don't have experience that way.) If someone needed a centralized source-control system, I would recommend Perforce, as long as they had the resources to license it.

On the other hand, I've recently been looking at some distributed source-control systems (git, Mercurial, and Bazaar, specifically). They have a lot of features that look very intriguing, especially not requiring the constant server connection. Additionally, you could set up your system to have a "main" server, even with the distributed systems. So I would suggest looking at one of those first, and see if they meet your needs.