How Perforce change list number works?
Perforce assigns numbers to changelists and also maintains a default changelist, which is numbered when you submit it. You can create multiple changelists to organize your work. For example, one changelist might contain files that are changed to implement a new feature, and another changelist might contain a bug fix. Changelists are renumbered so that submitted changelist numbers always ascend in chronological order.
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.
Perforce change list numbers are serial. Once a CL number has been assigned via a submit, only the next number in series will be used.
One way this could happen is that you had pending work in CL 326042 and something in your default and the latest submitted CL is 326041.
Reference
http://www.perforce.com/perforce/doc.current/manuals/p4guide/04_files.html
http://kb.perforce.com/article/781/changelist-renumbered-on-submit
- Use of runtime variables to save into another variable using register in Ansible - September 6, 2018
- Ansible & Ansible Tower Variable Precedence Hierarchy - September 6, 2018
- How to use template in Ansible? - September 6, 2018
Perforce changelist numbers are unique identifiers assigned to sets of file changes that help track and organize revisions across the repository; every time files are submitted, Perforce increments the changelist number to reflect a new version of the depot, making it easy to reference specific changes, audit history, roll back to previous states, and coordinate parallel work — this system ensures clarity and consistency in version tracking and collaborative development workflows.