Changelist Renumbered on Submit

SUMMARY

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.

DETAILS

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 

Change 38 created with 1 open file(s).
$ p4 changes -s pending
Change 38 on 2007/10/22 by bruno@depot-ws *pending* 'no description'

$ 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 a given changelist's number will be after submit.

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.