# The form data below was edited by perforce # 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. May also provide # additional information such as the earliest release # in which a bug is known to exist. # # Component: Projects may use this optional field to indicate # which component of the project a givenjob is associated # with. # # For the SDP, the list of components is defined in: # //guest/perforce_software/sdp/tools/components.txt # # Type: Type of job [Bug/Feature]. Required. # # Release: Release in which job is intended to be fixed. Job: job000217 Status: closed Project: perforce-software-p4convert Severity: C ReportedBy: ddvalk ReportedDate: 2015/04/27 13:07:34 ModifiedBy: perforce ModifiedDate: 2019/02/19 10:51:13 OwnedBy: ddvalk Description: Perforce labels spanning branches I'm using Convert mode and converting labels and branches. As it stands, the labels are applied to various branch versions. For example: $ p4 -p 1666 files @IPX_C19 //depot/icm/proj/USB30phy/BCG_28NM/rtl/rtl/files.f#5 - integrate change 247907 (ltext) //depot/icm/proj/USB30phy/BCG_28NM/rtl/rtl/usb30_core2dfe.sv#7 - integrate change 247935 (text+Fx) //depot/icm/proj/USB30phy/BCG_28NM/rtl/rtl/usb30_dfe.sv#8 - integrate change 247982 (text+Fx) ... //depot/icm/proj/USB30phy/BCM63381_A0/rtl/rtl/usb30_phy.sv#8 - integrate change 247971 (text+Fx) //depot/icm/proj/USB30phy/BCM63381_A0/rtl/rtl/usb30_rxpmd_clk_gen.sv#2 - integrate change 247858 (ltext) //depot/icm/proj/USB30phy/BCM63381_A0/rtl/rtl/usb30_txpmd_clk_gen.sv#2 - integrate change 247859 (ltext) ... //depot/icm/proj/USB30phy/main/rtl/rtl/usb30_mdio_creg.sv#1 - import change 247738 (ltext) //depot/icm/proj/USB30phy/main/rtl/rtl/usb30_mdio_csreg_5.v#2 - integrate change 247439 (text+Fx) //depot/icm/proj/USB30phy/main/rtl/rtl/usb30_mdio_csreg_8.v#2 - integrate change 247439 (text+Fx) All these files reside in the same directory in the tree - only differing because of the branch directory. Since these labels are applied on different branches, I cannot 'sync' to a label and pick up the entire fileset in one place. In CVS I would be able to run 'cvs get -r <label> <module>' and end up with all files tagged with that particular label - no matter the branch. During conversion, would it make more sense to apply the label to all the files on a particular branch so they're all visible? DevNotes: Type: Bug