We use Perforce for source control here at work. Perforce is a little different than other version control systems I have used in the past (CVS, Subversion, VSS) so I decided to read O'Reilly's Practical Perforce to help bring me up to speed.
It was a huge help. Much like Open Source Development With CVS, this book goes beyond just command documentation and tutorials to really explain the Perforce view of the software development process. As I said, Perforce operates a little differently than other version control systems and learning Perforce's approach to the software development process really helped me understand why Perforce works the way it does.
So your probably asking yourself, how is Perforce different? Well that answer could fill a book, but rather than telling you to RTFM I thought I'd focus on one key feature that I think really differentiates Perforce from other version control systems: the changelist.
Changelists are groups of changes submitted (committed) to the depot (repository) as one atomic transaction. When ever you open a file for editing (checkout) it is added to a changelist. You can have multiple files in a changelist and you can be working on multiple changelists at the same time.
This feature is great because it allows you to easily track all of the files associated with some unit of work. For example, lets say you are working on bug fix A, and you have edited files A, B and C. All three files are included in a changelist you have called "Bug Fix A." Now when it comes time to QA the bug fix, the QA team can pull the Bug Fix A changelist and get all of the files associated with this fix.
Another scenario where changelists can help is when you need to apply only certain changes. Let's say your developers have submitted bug fixes A, B, C and D but your QA team has only tested fixes A and D. Changelists let you easily "cherry pick" only those files included in changes A and D so that you can deploy changes as they are ready. (Note that cherry picking changes can be problematic if there are dependencies between changelists so not all changes may be able to be applied out of order.)
This packaging of changes is really just one aspect of Perforce, but I think it is a big one. I've worked for more that one company where we have tried to package changes together using some sort manual process or commit trigger. Perforce changelists handle this automatically, and usually much better.