What are the benefits of using Perforce instead of Subversion?

Question

My team has been using SVN for a few years. We now have the option of switching to Perforce.

What would be the benefits (and pitfalls) of making such a switch?

Answer 1

I currently use both on different projects.

• The perforce branching mechanism is superior.
• The perforce conflict resolve tool is better.
• I really like perforce's strong notion of a changelist.
• Perforce seems faster.
• It's easier to set up and get running.
• Some of our members really like the MS Office plugin for perforce, I'm on a Mac so I can't use it.

But

• The SVN clients are better, especially the eclipse plugin.
• Perforce is more expensive.

These are merely opinions, so perhaps this is a poor answer :)

If I was already using one or the other, I'd be very hard pressed to switch since neither seems to offer really significant benefits over the other, but the disruption in switching could be large.

Answer 2

Proper branching and making branches part of the namespace are the biggest benefits that I see in Perforce. Merging is easy. I see no downside in moving away from Subversion.

Answer 3

• P4 keeps track of your working copy on the server. This means that
  1. Large working copies are processed much faster. I used to have a large SVN project and a simple update took 15 minutes because it had to create a tree of the local working copy (thousands of folders). File access is slow. P4 stores the information about the working copy in the database, so any operations were always near-instantaneous.
  2. If you mess around with your files and do not tell the server, you are in trouble! You cannot just delete a file - you have to delete a file with the P4 client so the server knows. Note that if you locally delete a file, it will not be downloaded again on successive updates because the server thinks you already have it! When lots of this happened and I ended up wildly out of sync, I usually had to resort to cleaning out my local copy and downloading it again, which could be time-consuming. You must be careful about this.
• The Explorer shell extension client (think TortoiseSVN) sucks and is completely unusable.
• There are two GUI client applications which offer the best functionality: P4Win and P4V, of which P4V is newer and more easy to use but not as feature-rich.
• There are Visual Studio and Eclipse plug-ins, which work relatively well, although they do not have many advanced features.
• Generally speaking, P4 offers much less features than SVN and is sometimes downright confusing.
• Working copy definitions were nice and flexible. I believe P4 is superior to SVN here: you can define masks for working copy folders and create all sorts of bizarre trees, so you download only what you want to exactly where you want, without having to manually futz with multiple checkouts. This came in very handy when I had gigabytes of stuff on the server and only wanted a specific subset of it. I used SVN in a similar situation with much more hassle.
• Branching under P4 is... odd. Branchsets and different kinds of branches and confusing UI. I do not remember much details about this, unfortunately.

Other than that, it's pretty standard.

I recommend you keep SVN unless you deal with huge codebases or hate the .svn folders littering up your filesystem. SVN+TortoiseSVN is far more confortable for most situations.

Answer 4

I used SVN, not a lot, just to try it out. I used Perforce for about three years. I thought it was great. The customer service was brilliant, very fast to resolve a problem that err turned out to be just me being daft, and they even implemented a feature I suggested.

Some other developers and especially non developers who had to use it found it a bit tricky to learn to use, especially when it came to defining a client-spec (a map of folders on the server to local folders).

I found it to be very quick to get files in and out of, and to be very reliable. I think most developers I worked with really liked it once we'd got used to it. We were using Visual Source Safe before we switched though, so, pretty much anything is better than that.

Downsides, it costs money. I believe SVN is very good system, as SVN is free, I would think you'd have to have a compelling reason to switch especially as Perforce does take a while to learn. If SVN is doing the job for you, and you haven't got any complaints about it, I would suggest you stay with it, and save the money for a rainy day!

Answer 5

I have used both, and in my experience Perforce makes a lot of sense if you have a big team and/or codebase; otherwise I would pick SVN - it is easier to set up and maintain.

Answer 6

Has your team evaluated Git? It has features analogous to those available in Perforce, but is free (FOSS).

Either is a great alternative to SVN when working with a large team.

Answer 7

The main benefit of using subversion over Perforce is in my opinion ability to edit things off-line and simultaneously with your colleagues.

If the data infrastructure is loosely bonded (there is off-line time), svn rocks. You can do a lot even if the server would not be reachable. Perforce essentially requires an always-available server connection.

Disclaimer: my info on Perforce is old, used it for a while in 2005-06 before fully switching to svn

Answer 8

I use perforce at work, svn at home.

The perforce GUI is pretty nice, but only once you get used to it. It definitely has a learning curve, when non programmers start using perforce it usually takes some time until they get the concepts.

Tortoise is awesome, it's very easy to use. My lawyer wife subversions all her documents using it ;)

Branching is easy in perforce. In fact so easy, that people branch for not too much reason. Then you integrate because you branched. It can quite easily become the only thing you do.

Svn is integrated in more products. At least more products that I use. It's a great advantage, because if you have to use eithere external to your development environment, they both get clunky.

Every once in a while we have problems with perforce where it thinks that your local copies are up to date, but they are not. Then you have to force synce, then if it's still no good, delete your local files and resync. Never had such issues with svn. This is actually a huge problem as you don't even know you are working on an old copy.

Another thing to think about is why you want to change. If you have a system that works and everyone's familiar with it and happy with it, why replace it?

Answer 9

On the Perforce website they have a paper comparing the two: P4 vs SVN

Obviously, given the source, you have to realise that it stresses the advantages of Perforce over SVN, but it is still a useful read. You never know, one of the benefits may well be the killer item that your team could benefit from given your own unique circumstances.

I would certainly recommend Perforce for a number of reasons already covered in other answers, but I'm not in a position to offer a comparison with SVN having never really used it.

Answer 10

You can edit things offline in Perforce if you want. Your worksapce defines if files are readonly or writeable, so you could make them all writeable, hack away and then ask Perforce to figure out what needs to be checked in.

Better to have files readonly and check out what you need so others (and yourself) know what you have been/are doing.

The better system for you depends on what your requirements are, if you have no requirements then Perforce wins.

Who uses Subversion? Small non-commercial teams Cheap or small commerical teams

Who uses Perforce? Google Sony Samsung nVidia Symantec

Answer 11

Perforce licensing slides down in cost as number of seats goes up, as I recall. So it's not exactly $900 per seat. It's also a server-based license; you pay for total number of human developers using it, not per machine client using it. So, if you're a shop of 200 people, the 200 seat license lets them all use perforce, even from home.

Answer 12

As of recent versions, Perforce has a new feature for shelving changes:

Shelving is the process of temporarily storing work in progress on a Perforce Server without submitting a changelist. Shelving is useful when you need to perform multiple development tasks (such as interruptions from higher-priority work, testing across multiple platforms) on the same set of files, or share files for code review before committing your work to the depot.

This is analagous to git's branching model which lets you effortlessly switch from one local branch to another when you need to multitask.

AFAIK, Subversion has no similar feature.

More info on the Perforce blog.