p4 commands generally apply to the entire workspace. svn commands generally apply only to the current directory and all its subdirectories. If you want to restrict a p4 command to only the current dir and all its descendants, you can specify the '...' wildcard for the filespec.

working copy -- workspace: The files on your local machine that you manipulate.

repository -- depot: the files under revision control on the server

opened -- when you mark a file for editing using p4 edit, perforce call that "opened". By that terminology, svn considers every file in the working copy as opened.

Revision -- A particular version of a file. Each time you change a file, it gets a new revision number. This is just like CVS.

Changelist -- A numbered changeset. Each change to the repo gets its own number. Then you can move forward and back in time by syncing to a changelist number. Interestingly, if you tell p4 to sync to a revision number, but specify a changelist number, it will happily delete most of your files (because once a repository has been used for a while, no file will have a revision number anywhere near as high as most changelist numbers). Changelist numbers are analogous to Subversion's revision numbers.

svn tags <-> p4 labels.

svn hook scripts <-> p4 change review + p4 triggers

svn up/update -- p4 sync -- update your working copy.

p4 sync //sbronson/workspace/...@35647 -- syncs your entire workspace to a particular changeset number.

svn co/checkout -- There's no real dual... First use p4 client to set up a workspace then use p4 sync to check out the files. This command shows ALL client workspaces. To delete a client workspace, just remove its line in p4client and then sync.

svn ci/checkin -- p4 submit -- commit changes in your working copy to the repository

svn st/status -- p4 opened / p4 sync -n -- tell what files have been modified

svn revert -- p4 revert -- remove local changes from a file

svn add -- p4 add -- add a file to the working copy, gets added to repo on checkin

svn rm -- p4 delete -- delete a file from the working copy, gets deleted from repo on checkin.

svn mv f1 f2 -- p4 integrate f1 f2 ; p4 delete f1 -- Rename a file preserving full history

svn diff -- p4 diff -- show changes between local file and repo

svn cat -- p4 print -- show contents of a file

svn log -- p4 filelog -- print revision history for a file

svn log -- p4 changes -i directory/... -- print revision history for a directory.

-l -- print changesets with full checkin messages
-m -- limit the number of changesets printed

svn st -- p4 diff -se -- Show files that have been modified since last sync regardless of if they've been opened for edit

svn st -- p4 diff -sd -- Show files that have been deleted since last sync regardless of if they've been opened for edit

p4 edit -- svn has no corresponding command because all files are opened for edit, then any changes are merged back into the repository. I find this a much better way to work. (p4 offers a work mode like this doesn't it?)

p4 lock -- Prevents anyone else from making changes to that file. This is rather counter to svn's philosophy so svn doesn't offer any dual.

p4 has the same directory myopia that CVS does. You cannot create a directory -- you can only create files in directories. If you want to create a directory, you must create a .p4ignore hidden file in it (right? -- I haven't investigated). This appears to be a result of p4, like cvs, using rcs for its back-end.

Always sync before submitting a changeset. If you are notified of conflicts, resolve them with 'p4 resolve'. If there are no conflicting changes, you can just hit 'am' (accept merge) and let p4 do the merge. Otherwise, you'll have to hit 'e' and look for '>>>" to find the conflicting locations.


p4 change -- svn encourages you to make one change at a time. It allows you to name individual files in svn ci or delete files using the commit comment but this often leads to broken checkins. If you need to work on multiple changes at the same time, you generally run svn co to create multiple working copies of the same branch.

p4 allows you to keep multiple changelists in the same tree as long as they don't overlap. If you don't explicitly assign an existing changelist (p4 edit -c number) to your edits, your changes go in the default changelist.

To create a changelist, 'p4 change'. Leave the number as 'new' because p4 will assign you a number. You must remember this number; that's a little painful. 'p4 changes' to list existing changelists, p4 change -d number to delete a changelist.

Use p4 reopen to move opened files among changelists. 'p4 reopen -c default file' reassigns the file to the default changelist.


To split a single code line into two.

There are two ways to branch in p4:

  • Branch specification: first create a branch specification using p4 branch. Give it a name and specify the mappings the same as with p4 client. Then populate it using p4 integrate -b name and then p4 submit.
  • File specification: same as subversion, where branches are just directories in the filesystem.


To combine two code lines back into a single whole.

p4 merge -b branch -- Merge the changes from the branch back into the local tree.

Specify -i for a baseless merge (if p4 complains about no common ancesor)