Automatic labels

Automatic labels refer to the revisions provided in the View: and Revision fields of the label specification. To create an automatic label, fill in the Revision field of the p4 label spec with a revision specifier. When you sync a workspace to an automatic label, the contents of the Revision field are applied to every file in the View field.

Example Using an automatic label as an alias for a changelist number

Bruno is running a nightly build process, and has successfully built a product as of changelist 1234. Rather than having to remember the specific changelist for every night’s build, he types p4 label nightly20111201 and uses the label’s Revision field to automatically tag all files as of changelist 1234 with the nightly20111201 label:

Label:  nightly20111201
Owner:  bruno
Description:
        Nightly build process.
Options:     unlocked noautoreload
View:
        //depot/...
Revision:
        @1234

The advantage to this approach is that it is highly amenable to scripting, takes up very little space in the label table, and provides a way to easily refer to a nightly build without remembering which changelist number was associated with the night’s build process.

Example Referring specifically to the set of files submitted in a single changelist

A bug was fixed by means of changelist 1238, and requires a patch label that refers to only those files associated with the fix. Bruno types p4 label patch20111201 and uses the label’s Revision field to automatically tag only those files submitted in changelist 1238 with the patch20111201 label:

Label:  patch20111201
Owner:  bruno
Description:
        Patch to 2011/12/01 nightly build.
Options:     unlocked noautoreload
View:
        //depot/...
Revision:
        @1238,1238

This automatic label refers only to those files submitted in changelist 1238.

Example Referring to the first revision of every file over multiple changelists

You can use revision specifiers other than changelist specifiers. In this example, Bruno specifies to the first revision (#1) of every file in a branch. Depending on how the branch was populated, these files could have been created through multiple changelists over a long period of time:

Label:  first2.2
Owner:  bruno
Description:
        The first revision in the 2.2 branch
Options:     unlocked noautoreload
View:
        //JamCode/release/jam/2.2/src/...
Revision:
        "#1"

Because Helix Core Server forms use the # character as a comment indicator, Bruno has placed quotation marks around the # to ensure that it is parsed as a revision specifier.

Also in this section: