# 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: job000161 Status: open Project: p4perl Severity: C ReportedBy: reg_smith ReportedDate: 2015/03/03 09:31:44 ModifiedBy: perforce ModifiedDate: 2019/02/19 10:51:07 OwnedBy: reg_smith Description: Calling a p4 diff2 command using P4Perl $p4->RunDiff2 against a depot path that contains a file that has been renamed/integrated/renamed again returns the data structure in an unexpectedly different format. (referenced on p4prod:1666 by https://swarm.perforce.com/jobs/job077621) - In the case with no rename/integrate/rename, the hash values for the keys for rev,type and depotFile are strings as expected. - In the rename case the values are an array ref with 3 elements; the first 2 are empty and the last element is the expected value. It is specific to the case where the untagged output from diff2 contains on the left hand side e.g.: ==== - //jam/main/src/R.h#1 ==== ==== //jam/dev2.3/src/S.h#1 - === In my testing I renamed a file from Q.h to R.h on my //jam/main/src branch, and merge/copied the changes to //jam/rel2.3/src and then renamed the file from R.h to S.h on //jam/rel2.3/src. i.e. 1. rename //jam/main/src/Q.h to //jam/main/src/R.h 2. integrate //jam/main/src/R.h to //jam/rel2.3/src (so we have added //jam/rel2.3/src/R.h) 3. rename //jam/rel2.3/src/R.h to //jam/rel2.3/src/S.h The raw output from "p4 diff2 -S //jam/dev2.3" reports for the left hand file and the right hand file name is the old file name R.h before the rename to S.h on //jam/rel2.3/src/ p4 diff2 -S //jam/dev2.3 -q ==== - //jam/main/src/R.h#1 ==== ==== //jam/dev2.3/src/S.h#1 - === The tagged output from "p4 -ztag diff2 -S //jam/dev2.3 -q" appears sensible: ... status right only ... depotFile2 //jam/main/src/R.h ... rev2 1 ... type2 text ... status left only ... depotFile //jam/dev2.3/src/S.h ... rev 1 ... type text ..but if we execute the same command using $p4->RunDiff2, for the 'right only' entry, we get array refs for rev,type and depotfile with the first 2 out of 3 elements empty (rather than the values being strings for the case without a rename) $diff2=$p4->RunDiff2(-S => "//jam/dev2.3", '-q'); print Dumper($diff2); [ { status => 'right only', rev => [ <<< rev value is array ref undef, <<< empty undef, <<< empty '1' ], type => [ <<< type is array ref undef, <<< empty undef, <<< empty 'text' ], depotFile => [ <<< depotFile is array ref undef, <<< empty undef, <<< empty '//jam/main/src/R.h' ] }, { status => 'left only', <<< this is "normal" with rev,type,depotFile keys having string values rev => '1', type => 'text', depotFile => '//jam/dev2.3/src/S.h' } ] If we set tagged to off with $p4->Tagged(0) the output appears much like the raw p4 equivalent; [ '==== - //jam/main/src/R.h#1 ====', '==== //jam/dev2.3/src/S.h#1 - ===' ] So the information is there but you'd have to check if rev,type and depotfile are array refs to get to them in this case. Test script follows: ##### Start of test script use P4; use Data::Dumper; my $p4 = new P4; $p4->SetClient( $clientname ); $p4->SetPort ( $p4port ); $p4->SetPassword( $p4password ); $p4->Connect() or die( "Failed to connect to Perforce Server" ); $Data::Dumper::Indent = 1; $Data::Dumper::Terse = 1; $Data::Dumper::Quotekeys=0; # Turn off tagging #$p4->Tagged( 0 ); # disabled # Execute diff2 $diff2=$p4->RunDiff2(-S => "//jam/dev2.3", '-q'); # Check command execution for errors (defined as sub) checkifError(); # Print out data structure print Dumper($diff2); # Check for execution for errors sub checkifError { if( $p4->ErrorCount() || $p4->WarningCount() ) { print "P4 Errors:\n\n" . $p4->Errors() . "\n" if $p4->ErrorCount(); print "P4 Warnings:\n\n" . $p4->Warnings() . "\n" if $p4->WarningCount(); $p4->Disconnect(); print "Exiting on P4 error!\n"; exit; } } ##### End of test script DevNotes: Type: Bug