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

P4 CLI Documentation | 2025.2

# Automatic label examples

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

Your search for returned results