Can we create Labels in perforce

Question

I am working in a project. We use both clearcase and perforce.

As we are working on differnet builds, In clearcase we create a label for each release. Say for release "X", we create a clearcase case "Label X". Label X is having all the latest files with respect to release "X". When we finish another release say "Y", we create another label say "Label Y". Label "Y" is again having all the files for release "Y". But at any point of time we can go back to "Label X" .It means all the files will be reverted back to "Label X".

Can we do same thing in perforce? Can we create a label in perforce so at any point of time, we can go to that label which will give the files as in that label timeline.

Answer 1

Yes, you can create labels in perforce.

Use p4 label to create a label specification, and then use p4 tag to tag files with a label.

You can learn more about labels in the user guide.

Answer 2

Perforce also provide an interesting guide "Migration Planning Guide: IBM Rational ClearCase to Perforce", and mention that p4 label is not the only alternative:

Label Strategies

Both ClearCase and Perforce provide labels, which identify the versions of files that constitute a baseline. For many ClearCase users, labels are mandatory. Applying labels is time-consuming, often accounting for 30 percent or more of the time associated with creating stable builds.

In Perforce, labels are just one way of reproducing baselines. Changelists accomplish the same goal in ways that are less taxing on the build process and faster and easier to reference than a label.

Each Perforce check-in generates a unique changelist number that reflects the state of the repository at a point in time. Any changelist can be used to describe the state of every file in the repository, even though it affects only a small subset of the repository.

This is an oversimplication since a typical config spec is several lines or more.
Branches in Perforce are represented as directories, making it easy to combine branches and changelist numbers to represent a baseline.
Alternately, labels can refer to changelist numbers limited to an identified scope in the server, where the scope is typically a particular branch.

Answer 3

Imagine you have the following setup:

//depot/source/sourcefile.cpp
//depot/build/product.exe

At 8am, you check in sourcefile.cpp (now revision 2, in change list 100). The build machine starts building and at 9am, the build machine checks in product.exe, revision 2 in change list 104. Cool. Sadly, you may not have noticed, but at 8:15, someone checked in revision 3 of sourcefile.cpp in change list 103.

What are your options? If you just record the change list of the source (100) and product (104), you can sync your whole project to source and then sync further the contents of change list 104. This process is somewhat manual - you have to record two numbers and do a two step operation.

You can make a label, but sadly, labels don't allow multiple revisions so you it's not really workable.

Finally, at some point after you check in revision 104, you can create a branch. This is basically a metadata copy of the revisions you are interested in so that you can do a one click sync in the future. You can lock the branch to prevent changes.

p4 integ //depot/source/...@102 //depot/milestone1/source/...
p4 integ //depot/build/...@104 //depot/milestone1/build/...

Geeky details - you can configure files in perforce to hold a limited number of revision - for instance you might only want the last 16 revisions of product.exe. (Change the filetype to +S16). If you (or someone else does this), you the first two procedures will eventually fail because the revision has been deleted due to too many revisions. If you use the branch, your product.exe won't age out.