# The form data below was edited by super-tom_tyler # Perforce Workshop Jobs # # Job: The job name. 'new' generates a sequenced job number. # # Status: Job status; required field. There is no enforced or # promoted workflow for transition of jobs from one # status to another, just a set of job status values # for users to apply as they see fit. Possible values: # # open - Issue is available to be worked on. # # inprogress - Active development is in progress. # # blocked - Issue cannot be implemented for some reason. # # fixed - Fixed, optional status to use before closed. # # closed - Issue has been dealt with definitively. # # punted - Decision made not to address the issue, # possibly not ever. # # suspended - Decision made not to address the issue # in the immediate future, but noting that it may # have some merit and may be revisited later. # # duplicate - Duplicate of another issue that. # # obsolete - The need behind the request has become # overcome by events. # # Project: The project this job is for. Required. # # Severity: [A/B/C] (A is highest) Required. # # ReportedBy The user who created the job. Can be changed. # # ReportedDate: The date the job was created. Automatic. # # ModifiedBy: The user who last modified this job. Automatic. # # ModifiedDate: The date this job was last modified. Automatic. # # OwnedBy: The owner, responsible for doing the job. Optional. # # Description: Description of the job. Required. # # DevNotes: Developer's comments. Optional. Can be used to # explain a status, e.g. for blocked, punted, # obsolete or duplicate jobs. # # Component: Larger projects may use this optional field to # indicate which component of the project a given # job is associated with. # # Type: Type of job [Bug/Feature]. Required. Job: CBD-31 Status: open Project: perforce-software-cbd Severity: B ReportedBy: tom_tyler ReportedDate: 2017/05/17 12:19:08 ModifiedBy: super-tom_tyler ModifiedDate: 2017/05/17 12:21:11 OwnedBy: ttyler Description: Change default sync rev for '...' on a back-in-type sync. Change the default revision used for a 'p4 sync' when a back-in-time sync is done, i.e. a sync with a revision specifier, thus selecting an older version of the *.cbdsst file (which represents the state of the versioned stream spec at the old revision). Currently, when a back-in-time sync is done, the sync uses the correct specified revisions when they are specified explicitly in the older version of the *.cbdsst file, e.g. a Paths: field containing: import foo/... //foo/main/...@275 However, if no revision is explicilty specified, e.g.: import foo/... //foo/main/... the current behvaior is simply to pass the '...' along to the server, resulting in the head revisions being selected for a sync to files in //foo/main/... With this job, the desired new behvaior is to make it so the implicit default, when no revision is specified, becomes the point specified changelist number. So, if a user does: p4 sync @500 and that results in syncing a //ace/main/ace.cbdsst@500, and in that revision there is a Paths: field containing: import foo/... //foo/main/... then desired behavior is to translate that sync to the equivalent of: p4 sync //foo/main/...@500 == OPTIONAL == For visual optimization, the @500 could be replaced with the latest changelist up to @500 that actually affected files in the path //foo/main..., and so it might actually get translated to something like: p4 sync //foo/main/...@275 assuming @275 is the latest changelist up to @500 that affected files in //foo/main/... In all cases, 'p4 sync' behavior also applies to 'flush' and 'update' commands (which is current behavior). Type: Feature