What are the advantages to Perforce?

Question

What are the benefits of Perforce?

I'd love to have some insight as to how Perforce can work better in a given situation than, say, svn.

If you have experience with both perforce and svn and you don't believe that there are any advantages, or believe that svn has advantages over perforce, I'd like to know why, as well.

Answer 1

Personally, I despise perforce. It's user interface is horrible, complicated, and simply non intuitive. It is buggy and crashes often.

I have worked with SVN before (via Tortoise SVN) and have found it much more simple and friendly.

Of course all of this is from a users point of view, probably SCMs have a different perspective

Answer 2

I agree with the previous Yuval - having worked with Perforce and svn, both in GUI and command-line mode, I prefer svn. However, the company I worked for at the time switched from the free cvs it was using to Perforce. Its GUI is flashier. I think its commit model is different - it uses locking, which may be preferable to some developers/managers. In a commercial setting, having support people for your version control tool may help too. I have heard that in some large companies using open-source code in production environments is forbidden, because they want to be able to get support for every line of code.

Answer 3

Perforce supports locking, and seems to require it for some file types that cannot be merged (binary resources, think images etc). It does not, however, require locking for ordinary source files, those can be opened for editing by multiple users at the same time, and then merged back into the depot.

I find Perforce's system with "changelists", that group changes to multiple files and treat them as a unit, nice. I'm sure you can do something similiar with SVN, but it's not as easy out of the box.

Answer 4

Perforce has the a bit different model than, say, svn. Every file is always locked in your working copy, and you have to declare to perforce you'll start editing it. This has e.g. the advantage that you can always immediatly see who else is working on a file.

All in all differences with other SCM's aren't very huge. You encounter Perforce in many places because at a time it was one of the few (if not the only) partially decent SCM that worked on Windows and Mac.

If I'm not mistaken you can use it for free with a limited number of clients, so you can try it out without much pain...

Answer 5

I've worked with Perforce for years, as well as Clearcase, Sourcesafe, RCS, PVCS, CVS and Subversion. More recently I've started using GIT too.

From this experience my opinion is that, for most purposes, Perforce is the best version control system for commercial environments. While not as simple, initially, as Subversion, it has a number of more powerful features, especially around branching and merging. The "lock by default" approach is generally more suited to this environment.

For personal stuff, small collaborative projects, small start-ups, or open source projects I find Subversion is better suited in many cases. They have different approaches, different ways of working. You can't just line them up on a scale and say which is best.

That said I hate ClearCase. ClearCase is usually forced down from above (ie a management decision).

For many of the cases where Subversion trumps Perforce many people seem to prefer the distributed systems like GIT, Bazaar, Mercurial, these days. From what I have seen of GIT they may well be right and I'm sure other posters will bear that out.

Answer 6

You might find hints in What are the benefits of using Perforce instead of Subversion? (just following your Perforce tag...).

We use Perforce at work and while I have little experience with various SCM software, I find this one quite well done, with a good GUI (on Windows), good command line support, lot of nice features... Might take a while to get used to its logic, but it is probably true for most SCM, I think.

Answer 7

One of Perforce's big selling points is speed. The server keeps track of the state of the files on the client; therefore, operations like "get me the latest state of the depot" are trivial -- the server already knows what files you have, and it can send the minimal amount of information back to you.

This advantage also introduces a disadvantage, in that the server and client can get out of sync if you edit files locally without checking them out first, move files locally without carrying out an integration, or delete files locally.

Because the Perforce server only sends the bare minimum of data to the client, Perforce performs well over slow links, such as a situation where a client in the US accesses a depot in London. Having said that, the Perforce protocol is relatively 'chatty', so it is susceptible to slowdown over congested links.

Answer 8

I use perforce at work daily and I would not recommend it to anyone. I'm sure it was maybe the best SCM for years but it's core model is outdated.

Perforce is maybe the most centralized SCM system I ever used. Imagine that they are proud of not caching anything on your disk. Doing a sync is annoying because in a huge number of cases it will do nothing unless you do not do a forced sync - and a forced sync does copy everything from the server back to you - if your project is 10GB it will copy all of them.

I have previous experience using SourceSafe, CVS, SVN, Mercurial and git (less of the last two).

I think that most open-source SCMs are mature and you can choose one of the. If you want something centralized go for SVN and if you want something decentralized use Mercurial (I had bad experiences with git on Windows).

Some other issues I had with perforce:

• what you commit is not what you get back: for example if you commit an UTF16 file on an Intel Mac and sync it from another PPC Mac you'll get another UTF16 file because perforce is smart and does covert you the file to the client byte-ordering. UTF16-BE - UTF16-LE ?!
• scripting perforce is 10x times harder than other tools.
• if you start using it and tie it to your processes by scripting probably you'll die with it because everything is done in perforce way and perforce way :(
• image that it's very easy to get down a p4 server: just do sync on the root of the project. Where I work this is not allowed because it can take the serve down! There is a watching script that is monitoring the perforce server processes and if one of them is taking over x GB of RAM it does kill it and send you a notification. Yes, doing one simple command on the client can create a 3GB process on the server in 5-10 seconds.