Here is a quote from Wikipedia that explains what I mean by Anti-Patterns:
In software engineering, an anti-pattern (or antipattern) is a design pattern that appears obvious but is ineffective or far from optimal in practice.
In Perforce, anti-patterns often appear when a team adopts Perforce but uses the new SCM system in the same way as it used the previous system without realizing the new benefits. This might work for some time, but often the old ways do not scale when the database size has reached the limit of the allocated hardware.
Here is an example I have encountered that could qualify as an anti-pattern:
Excessive use of labels:
Perforce offers labels like most other SCM systems and measured use of labels is not a problem. The trouble starts when labels are used all the time by automated tools, creating hundreds of labels a day tagging thousands of files. After some time the table that holds the reference between the labels and the tagged file revisions starts to grow until all operations in Perforce that deal with labels slow down noticebly.
In many cases, these labels can be avoided:
- Use changelists. They are there already, they have little overhead and they are much faster than labels.
- Use automatic labels: they can be used as a symbolic name for a changelist (http://www.perforce.com/perforce/doc.082/manuals/p4guide/06_codemgmt.html#1081816)
- Use branches: instead of tagging released versions in the mainline, branch the code into a release code line.
Note: I did not say "Do not use labels", I only said use labels with sense (see the "It depends" Blog entry from Tom Tyler on the consultant view on that).
More anti-patterns to follow in later posts.