6 messages in com.perforce.p4ruby[p4ruby] diff output| From | Sent On | Attachments |
|---|---|---|
| bob p4 | 11 Mar 2008 12:55 | |
| Jeff A. Bowles | 12 Mar 2008 10:37 | |
| Jeff A. Bowles | 12 Mar 2008 10:43 | |
| bob p4 | 12 Mar 2008 11:59 | |
| Jeff J. | 13 Mar 2008 14:27 | |
| Andy Koch | 14 Apr 2008 15:07 |
| Subject: | [p4ruby] diff output |
|---|---|
| From: | bob p4 (jeff...@gmail.com) |
| Date: | 03/12/2008 11:59:40 AM |
| List: | com.perforce.p4ruby |
On Wed, Mar 12, 2008 at 1:44 PM, Jeff A. Bowles <jab at pobox.com> wrote:
Here is an example of overlaying a "run_describe" to make it more usable for a situation specific to my application. This might be general enough for someone else, and might not, but shows a very reasonable way to overlap a p4.run("describe"............) call. Note that p4.run_describe(.......) does the postprocessing but p4.run('describe'.......) does not.
Again, use the interface to make it right - the P4Perl intention, as Tony explained it when he did it, was that you could build on top of this as you needed but that it would get out of your way if you wanted.
I have done similar things for "p4.run_depots" (to call 'p4.run("depots") once, and then cache the results for the rest of the run of the application) and "p4.run_print" (since the output of 'p4.run("print".....)' gives me chunks of the file that need to be reassembled.
I understand there may be a need to massage the output into some desired form, but my point is a somewhat separate issue.
We have an array of hashes. Each hash already contains the parsed version of the raw perforce output. Each hash contains the information for a specific file. One file, one hash.
Except this is not the case. Some elements in the array are strings which pertain to the previous hash. Remember, the perforce output has already been parsed. Those strings should not be floating around aimlessly. They are tied to a specific file. They should be included in the hash which describes the file to which they belong.
--Jeff