What are the benefits of using Perforce instead of Subversion?

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?

• 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.

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.

Update: Since writing this, I've completely switched to using GIT for both personal and commercial purposes. I would pick it over either SVN or Perforce any day.

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.

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?

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.

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.

Perforce allows the server to own the client.

A Perforce server can read and write arbitrary files on the client, and thus execute arbitrary code. The Perforce configuration is all server-side, so the server could simply treat the entire hard disc of the clients' computer as a repository, and do whatever it wanted to it.

Never run Perforce except in an SELinux sandbox.

Remember: The Perforce client is the server's puppet. You must use the operating system's security features to prevent it from doing something you don't want it to do. ALWAYS treat the Perforce client as hostile.

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!

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.

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

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.

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.

In my opinion reason#1 for selecting between SVN and Perforce is cost.

Small repositories: SVN does its job just fine and for free.

Big repositories: It is fatal to use SVN: http://yoawsconsult.blogspot.com/2009/05/whenwhy-you-cant-afford-to-use.html. Perforce can do big repositories, but you have to pay for it and for getting to know it.

one disadvantage of perforce against sub version is export command in svn. It is easier to export or download the code of some version to anywhere. you do not need to create workspace for that. But in perforce you can get the version-ed code to your workspace only.

From my practice:

• Perforce designed to store also huge blob files (like software distributions), svn store all its data as text. It is impossible to store such binary data effectively in svn

• Perforce support usefull thing like "shelve changes". User asked perforce to store change like a "patch" in the perforce server. Another users then can review changes if author asked them. Svn doesn't support it

• Svn command line format is more easier to understand and remember and for daily usage

• Svn is free

• In "git" and in "svn" you edit you changes directly via editing files in local filesystem after receiving files from repo. In perforce "the right" way to work with files is to marked them that you're going to work with them (p4 edit)....In theory another guys will be available to view it, in practice it is not comfortable

• Perforce client workspace prepare in your local system need more time then svn due to extra configuration that should be done

Being able to do everything just from the exlorer via TortoiseSVN feels very comfortable! So there is even a P4 Extention installed. But its really not that sophisticated!

On the other hand the P4 client offers a accessible view onto the server repository so one can work without a complete checkout. This always felt a little cumbersome in SVN days with TSVN only.

Saying this I can not understand the top posters comment:

> - The Explorer shell extension client (think TortoiseSVN) sucks and is completely unusable.

For FOSS TortoiseSVN is just great! (Even though the icon thing worked a little bitchy and different on each machine..)

with TortoiseSVN you:

• can rearrange functions
• to bring 'get lock..' front for instance
• have actually access to ALL functions from explorer
• have icons in the shell menu
• are notified about updates

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