Perforce Public Knowledge Base - Changelist Renumbered on Submit
Reset Search
 

 

Article

Changelist Renumbered on Submit

« Go Back

Information

 
Problem

Changelists are renumbered so that submitted changelist numbers always ascend in chronological order. For more information on changelist renumbering see Chapter 4 of the Perforce User's Guide.

Solution

Pending numbered changelists might be renumbered when they are submitted to ensure that submitted changelist numbers are always ascending in chronological order. For example, if changelist A is submitted before changelist B, then changelist B's number will be higher when it is submitted. The following is an example of how a changelist is automatically renumbered:

Example

$ p4 edit hello.c
$ p4 change 
[ add a change description, then save this new change ]
Change 38 created with 1 open file(s).

Here is the pending change:

$ p4 changes -s pending
Change 38 on 2007/10/22 by bruno@depot-ws *pending* 'no description'

Other submissions have been made, so when change 38 is submitted the change is renumbered:

$ p4 submit -c 38
Submitting change 38.
Locking 1 files ...
edit //depot/code/hello.c#8
Change 38 renamed change 43 and submitted.

Changelist renumbering is necessary to ensure that commands that operate on submitted changelist ranges (such as p4 files @1,@1234) return sensible results. Renumbering helps users make assumptions such as: "if changelist N was the last one I synced to, then I do not have any changes from any changelist whose number is higher than N".

The changelist number is only finalized when the submit succeeds. It is not possible to predict with certainty what the submitted changelist number will be.

A "change-commit" trigger or the $Change$ RCS keyword, which requires the file to be ktext, are two possible ways to grab the final change number, because both of these are updated only when the submit is final.

Translating between old and new change numbers

When using change numbers to identify file revisions, Perforce works with the submitted change number. In the example above, change 38 is renumbered on submit to change 43. Running 'p4 describe' for the original change number reports "no such changelist" - change 38 doesn't exist as a submitted change.

$ p4 -ztag describe -s 38
38 - no such changelist.

However, the old change number is recorded in the database, allowing you to identify the original change number from the new one or identify the new change number from the old.

Firstly, working from the submitted change to find the original change number.

Running 'p4 describe' in tagged mode will show you more details about the submitted change, including the original change number if it has been renumbered.

$ p4 -ztag describe -s 43
... change 43
... user bruno
... client depot-ws

... status submitted
... oldChange 38

(The output has been reduced to show only the relevant text.)

Next, starting with the original change.

In the 2012.1 Server release, the '-O' flag was added to both p4 change and p4 describe. This allows you to specify the Original change number, and Perforce will report change details for the submitted change. For example, here's the change:

$ p4 change -o -O 38 

Change: 43

Date:   2007/10/22 12:36:14

Client: depot-ws

User:   bruno

Status: submitted

Description:
        no description

and similarly the output of 'p4 describe':

$ p4 describe -s -O 38
Change 43 by bruno@depot-ws on 2007/10/22 12:36:14

        no description

Affected files ...

... //depot/code/hello.c#8 edit
Tagged output is available for many commands. This is achieved by adding '-ztag' as a parameter to the 'p4' executable, prior to the command you wish to run - as shown in the example above. The information reported in tagged output may differ slightly between server versions.
Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255