[ACCEPTED]-What are the benefits of using Perforce instead of Subversion?-perforce

• 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 4 recommend you keep SVN unless you deal with 3 huge codebases or hate the .svn folders 2 littering up your filesystem. SVN+TortoiseSVN 1 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 10 are merely opinions, so perhaps this is 9 a poor answer :)

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

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

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

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

I use perforce at work, svn at home.

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

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

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

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

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

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

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

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

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

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

Perforce allows the server to own the client.

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

Never run Perforce except in an SELinux 3 sandbox.

Remember: The Perforce client is the server's puppet. You must use the operating system's 2 security features to prevent it from doing 1 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 24 used Perforce for about three years. I thought 23 it was great. The customer service was brilliant, very 22 fast to resolve a problem that err turned 21 out to be just me being daft, and they even 20 implemented a feature I suggested.

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

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

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

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

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

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

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

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

Who 1 uses Perforce? Google Sony Samsung nVidia Symantec

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

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

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

AFAIK, Subversion 1 has no similar feature.

More info on the Perforce blog.

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

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

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

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

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

From my practice:

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

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

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

• Svn is free

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

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

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

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

Saying this I can not understand 4 the top posters comment:

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

For FOSS TortoiseSVN 3 is just great! (Even though the icon thing 2 worked a little bitchy and different on 1 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