Perforce for a Subversion user?

Question

I've just changed jobs. My previous employer uses Subversion, my new employer uses Perforce.

Are there any resources out there that'll help me, as a user, change my mental model from a Subversion one to a Perforce one? What are the analogs to common SVN commands? Which concepts are implemented differently?

I'm not particularly interested in the pros and cons of Perforce vs Subversion - the decision's been made. There are plenty of other questions on S.O. covering that. I'd like to know what mental readjustment I'll have to make (or not).

Answer 1

A few things come to mind (I have used perforce four years ago - things may have changed).

• locking - perforce requires you get a lock on files you are working on. Subversion doesn't.
• changelist - changelists are basic to working with perforce. Every commit is of a changelist. They are less important in subversion.

This blog post may help you make the transition.

Answer 2

Even if it is not the most current presentation, you still have a good features array (in Perforce and SVN) in this document.

It can be useful to read Perforce Branch Naming and Repository Structure Guidelines, as its structure is a bit like the one in SVN: Perforce uses the repository structure to represent branches as well as other directory structures.

Answer 3

Perforce and Subversion are quite similar, they both feature atomic commit of groups of files, and path-based branching.

Perforce has:

a) Pending changesets - you can group files that you are editing into groups and manipulate the groups.

b) Client-Specs - you can map the repository to your local work-space in quite complicated schemes.

c) No external - so you can't map the same part of the repository to multiple locations in your work-space, or map other repositories to sub-dirs in your work-space.

d) Merge-tracking, which is a new feature for Subversion.

e) Strong server connections: You have to tell the server before editing a file, and the server uses this information to keep a good idea of your local work-space state, which makes updates faster.

Answer 4

I've just slid the other direction. My previous employer was using Perforce (Linux servers, Mac & Windows clients), my new employer is transitioning to SVN. Here's what I've run into:

• I do not miss Perforce's branching. This could have been the environment though.
• You Must Lock! But at least you can setup multiple locks and checkins.
• I hated Perforce's "command line", you can get used to it, but it was never simple.

I'm still not a fan of Perforce, so ymmv. Mostly get used to using the provided UIs, locking as your employer requires, and be careful on which changelist your working on (very easy to get buried in change lists).

Answer 5

Perforce is SOOOO much faster than SVN because all the check-outs are stored on the server so it doesn't have to check every file on an update. SVN works much better when disconnected from the network - with Perforce you have to tell the server when you've done a checkout. It's Windows GUI is really good. Command line isn't as easy as SVN. Google uses it!