At my current company I have to use perforce. I’ve used cvs and subversion recently, and I tend to think about revision control in terms of thsose. So here is my start of a cvs to perforce dictionary. This post will be edited as I learn more:
The format is
cvs command : perforce command — comment
- cvs diff : p4 diff — hey some things are easy
- cvs commit : p4 submit — note that the p4 version tends to be done with a change log
- cvs commit : p4 resolve —when you submit a file, the server compares the version you checked out to what is in the repo. If changes have come in since you checked out, perforce will prompt you to merge them by hand. cvs commit does this automatically, and will report any failures in automatically merging.
- cvs status : p4 opened — this shows only the files that are opened but that were already added to the repo. cvs status has a lot more info than this.
- cvs update : p4 sync
- cvs blame: p4 filelog — not really a direct translation, but a starting point. filelog is really more like cvs history.
Key perforce commands that have no cvs analogues:
p4 change –creates a change set, a subset of the files in the current directory that will be commited together.  Thus a p4 submit -c <changlist#> could only be reproduced in cvs by somehow generating a list of a files you wanted to revision control together. CVS does not tend to be used that way.
p4 client — perforce controls everything on a centralized server. It also requires you to explicitly check out a file before editing. You must create a client to get any work done. the p4 client command both creates a client, and allows you to name it. domain dns .