Tips on using the Perforce version control software. See also CVS tips and notes on using Subversion.
Keyword Support
I always enable keyword support on scripts and configuration files, as knowing where a file came from can speed debugging and resolving issues: without keywords, where did the file come from? How does one chase it back to the source respository, so that production changes can be properly backfilled? While these questions may be answered by other means, a $Header$ tag saves time. In script and configuration templates, I include:
# $Header$
# $Author$
# $Date$
This indicates at a glance where the file came from, who last edited the file, and when that edit was made. Granted, someone can still manually edit the file in production, but detecting that sort of problem is a role for the configuration management software, not version control. Use p4 edit -t text+kx … or p4 reopen -t text+kx … to set keyword expansion and execute bits on scripts.
Note that certain languages may trip up keyword expansion, such as the string "file=$File::Find::name, pid=$$" in Perl. However, this can be caught with testing, and suitable workarounds made, rather than disabling keyword expansion.
Change Sets
Use change sets to group related file edits together. This helps peers focus their code review on the salient files, without needing to instruct them on which files opened for edit are relevant. Sets also help prevent unrelated edits from being accidentally committed when the default change set is quicky submitted to perforce.
- p4 change - create a new change set. Alter the default list of open files as necessary.
