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 <none> on the left hand side e.g.:
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 <none> 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/
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)