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.labeltable. - 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.
