Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 CLI Documentation | 2025.1

# Automatic labels: superior performance

Automatic labels perform much better than static labels when synced because they are aliases for changelists.

- Static labels must store information for every file revision associated with the label. Sites using a large number of static labels with a large number of revisions have a very large `db.label` table.
- Automatic labels using a changelist revision do not require storing each file revision, which greatly reduces the amount of data that must be stored and scanned when referencing the label.

When using automatic labels containing both `View:` and `Revision` fields, use of the automatic labels to represent a revision ranges might not produce the same results when using the equivalent changelist revision range. You can make an automatic label behave exactly like its revision specifier by leaving the `View` field blank. Without this field, the automatic label is considered a pure alias and is processed exactly like the revision specification.

A changelist number can apply to more files than the number of files submitted by the changelist.

For example, putting `@1234` in the `Revision` field and `//depot/...​` in the `View` field of a label spec creates a label that is an alias for changelist `1234` for all files within `depot` at the time the change was submitted, even if only one file revision was submitted with the change.

Changelist numbers increment in chronological order, and automatic labels can be used as fixed points for any file or set of files in your depot.

Your search for returned results