Labels

A Perforce label is simply a user-determined list of files and revisions. The label can later be used to reproduce the state of these files within a client workspace.

Labels provide a method of naming important combinations of file revisions for later reference. For example, the file revisions that comprise a particular release of your software might be given the label release2.0.1. At a later time, all the files in that label can be retrieved into a client workspace with a single command.

Create a label when:

• You want to keep track of all the file revisions contained in a particular release of the software;
• There exists a particular set of file revisions that you want to give to other users; or
• You have a set of file revisions that you want to branch from, but you don't want to perform the branch yet. In this case, you would create a label for the file revisions that will form the base of the branch.

Why Not Just Use Change Numbers?

Labels share certain important characteristics with change numbers: both refer to particular file sets, and both act as handles to refer to all the files in the set. But labels have four important advantages over change numbers:

• the file revisions referenced by a particular label can come from different changelists;
• a change number refers to the state of all the files in the depot at the time the changelist was submitted; a label can refer to any arbitrary set of files and revisions;
• the files and revisions referenced by a label can be arbitrarily changed at any point in the label's existence; and
• changelists are always referred to by Perforce-assigned numbers; labels are named by the user.

Creating a Label

Labels are created with p4 label labelname.; this command brings up a form similar to the p4 client form. Like clients, labels have associated views; the label view limits which files can be referenced by the label. Once the label has been created, the
p4 labelsync command is used to load the label with file references.

Label names share the same namespace as clients, branches, and depots; thus, a label name can't be the same as any existing client, branch, or depot name.

Ed has finished the first version of filtering in elm; he wants to create a label that references only those files in the filter and hdrs subdirectories. He wants to name the label filters.1; he types p4 label filters.1 and fills in the resulting form as follows:

Label: filters.1 Owner: edk Description: Created by edk. Options: unlocked View: //depot/elm_proj/filter/... //depot/elm_proj/hdrs/...

When he quits from the editor, the label is created.

Before following this example further, it's worth stopping for a moment to examine exactly what has and hasn't been accomplished. So far, a label called filters.1 has been created. It can contain files only from the depot's elm_proj filter and hdrs subdirectories. But the label filters.1 is empty; it contains no file references. It will be loaded with its file references with p4 labelsync.

The View: field is used to limit the files that are included in the label. These files must be specified by their location in the depot; this view differs from other views in that only the depot side of the view is specified. The locked / unlocked option in the Options: field can prevent p4 labelsync from overwriting previously synced labels (this is described further in "Preventing Accidental Overwrites of a Label's Contents" on page 61).

Adding and Changing
Files Listed in a Label

Once a label has been created, references to files can be included in the label with the labelsync command. The syntax for labelsync is

p4 labelsync [-a -d -n] -l labelname [filename...]

The rules followed by labelsync to include files in a label are as follows:

1. All files listed in a label must be contained in the label view specified in the p4 label form. Any files or directories that are not mapped through the label view are ignored by labelsync. All the following rules assume this, without further mention.
2. When labelsync is used to include a particular file in a label's file list, the file is added to the label if it is not already included in the label. If a different revision of the file is already included in the label's file list, it is replaced with the newly-specified revision. Only one revision of any file is ever included in a label's file list.
3. If labelsync is called with no filename arguments, as in

p4 labelsync -l labelname

then all the files mapped by the label view will be listed in the label. The revisions added to the label will be those last synced into the client; these revisions can be seen in the p4 have list. Calling labelsync this way will replace all existing file references with the new ones.

Ed has created a label called filters.1 as specified above; now he wants to load the filters.1 label with the proper file revisions. He types

p4 labelsync -l filters.1

and sees the following:

//depot/elm_proj/filter/Makefile.SH#20 - added //depot/elm_proj/filter/actions.c#25 - added <etc.>

The file revisions added to the label are those contained in the intersection of the label view and the current client have list.

1. If p4 labelsync is called with filename arguments, and the arguments contain no revision specifications, the head revisions of these files are included in the label's file list.

After performing the above labelsync command, Ed finds that the file filter/filter.c is buggy. He fixes it, submits the new version, and wants to replace the old revision of this file in the label filters.1 with the new revision. From the filter subdirectory, he types

p4 labelsync -l filters.1 doc/filter.c

and sees

//depot/elm_proj/filter/filter.c#15 - updated

The head revision of filter.c replaces the revision that had been previously included in the label.

1. If labelsync is called with filename arguments that contain revision specifications, these file revisions are included in the label's file list.

Ed realizes that the version of filter/audit.c contained in his label filters.1 is not the version he wants to include in the label; he'd prefer to include revision 12 of that file. From the main Elm directory, he types

p4 labelsync -l filters.1 filter/audit.c#12

and sees

/depot/elm_proj/filter/audit.c#12 - updated

This revision of audit.c replaces the revision that had been previously included in the label.

Previewing Labelsync's Results

The results of p4 labelsync can be previewed with p4 labelsync -n. This lists the files that would be added, deleted, or replaced in the label without actually performing the operation.

Preventing Accidental Overwrites of
a Label's Contents

Since p4 labelsync with no file arguments overwrites all the files that are listed in the label, it is possible to accidently lose the information that a label is meant to contain. To prevent this, call p4 label labelname and set the value of the Options: field to locked. It will be impossible to call p4 labelsync on that label until the label is subsequently unlocked.

Retrieving a Label's Contents into a Client Workspace

To retrieve all the files listed in a label into a client workspace, use
p4 sync files@labelname.. This command will match the state of the client workspace to the state of the label, rather than simply adding the files to the client workspace. Thus, files in the client workspace that aren't in the label may be deleted from the client workspace.

Lisa wants to retrieve all the files listed in Ed's filters.1 label into her client workspace. She can type

p4 sync //depot/...@labelname

or even

p4 sync @labelname

But she's interested in seeing only the header files from that label; she types

p4 sync //depot/elm_proj/hdrs/*@filters.1

and sees

//depot/elm_proj/hdrs/curses.h#1 - added as /usr/lisag/elm/hdrs/curses.h //depot/elm_proj/hdrs/defs.h#1 - added as /usr/lisag/elm/hdrs/defs.h //depot/elm_proj/hdrs/test.h#3 - deleted as /usr/lisag/elm/hdrs/test.h <etc>

All the files in the subdirectory hdrs that are within the intersection of Ed's filters.1 label and Lisa's client view are retrieved into her workspace. But there is another effect as well: files that are not in the intersection of the label's contents and //depot/elm_proj/hdrs/* are deleted from her workspace.

If p4 sync @labelname is called with no file parameters, all files in the client that are not in the label will be deleted from the client. If this command is called with file arguments, as in p4 sync files@labelname, then the client workspace at the intersection of the depot, the client workspace view, and the file parameters will be updated to match the contents of the depot at that intersection.

Deleting Labels

A label can be deleted in its entirety with

p4 label -d labelname

Files can be deleted from labels with

p4 labelsync -d -l labelname filepatterns

A variant of this is

p4 labelsync -d -l labelname

This command deletes all the files from the label's file list, but leaves the empty label in the system.

Label Reporting

The commands that output reports on labels are:

Command	Description
p4 labels	Report the names, dates, and descriptions of all labels known to the server
p4 files @labelname	Lists all files and revisions contained in the given label.
p4 sync -n @labelname	Shows what p4 sync would do when retrieving files from a particular label into your client workspace, without actually performing the sync.