[p4] Scripting with perforce, pitafalls ...

Jeff A. Bowles jab at pobox.com
Mon Mar 3 08:39:13 PST 2008


As an aside, Tony Smith did a terrific presentation at the Perforce User
Conference a while back on p4ruby/p4perl, which is a loadable library for P4
work in each of those languages.  Robert Cowham responded with a p4python.
 Each is terrific, and if you can reframe the problem so that one of these
tools can fix it, life can be quite nice.
For example, in p4ruby, your "success/failure" worries turn into "did
anything throw any exception" (there are a couple of things you have to code
for / work around).   (You can, for example, say "I'll look at the exception
and decide that 'all files in sync' is an information message and not a
fatal error and return control to the script, but other ones will be
fatal.")  It's nice.
The guy asking about writing his own interface using the C/C++ API might
find that p4perl / p4python / p4ruby makes things light-years better. (Wait,
that's mixing metaphors, like "the Falcon made the  Kessel Run in less than
twelve parsecs".  Oh, well.)

  -Jeff Bowles

ps. If you're playing these scenarios out, by the way, remember the basic
rule of database applications programming: don't bury the server with
queries / requests.  One big call ("p4 fstat") might provide the information
for three other calls ("p4 have" and "p4 opened" and "p4 where" all can be
lumped into one call of 'fstat') with less networking overhead.  You
normally don't see the overhead, but if you run "p4 have" on 200,000 files
in a tight loop, invoking 'p4 have' 200,000 times, you'll see it.... (and
that's the simple case.)  So, "loop through the results, not through the
calls to the database."



On Mon, Mar 3, 2008 at 8:08 AM, Jeff A. Bowles <jab at pobox.com> wrote:

> Step on: know what tools are available for the script writer.
> Option #1:  normal 'p4' command usage.
>
>
> Example:  "p4 sync" / "p4 files" / "p4 submit -i"
>
>
> Good/bad:
>
>
>    - simple, but you are parsing formatted output.
>    - Filenames with embedded spaces are headaches.
>    - Getting status / success-fail is harder.
>
> Option #2: Use "p4 -s" for easier status / success-fail processing.
>
> Example:  "p4 -s sync" / "p4 -s files"
>
>
> Good/bad:
>
>
>    - simple, but you are parsing formatted output.
>    - Filenames with embedded spaces are headaches.
>    - Getting status / success-fail is slightly easier. You still need
>    to decide whether the command worked or not. ("Exit status" from the 'p4'
>    tells you whether the protocol worked, not whether the command worked, so
>    '-s' helps.)
>
> Option #3: Read up on tagged output.
>
> Example:  "p4 -Ztag  sync" / "p4 -Ztag files"
>
>
> Good/bad:
>
>
>
>    - Output is name/value pairs, far easier to parse.
>    - Filenames with embedded spaces are easier to parse / work with.
>    - Many (nearly all) examples of tagged output are parseable easily
>    in Perl.
>    - "p4 -Ztag describe" is a bit of a nuisance if the description is
>    multiple paragraphs. (You'll see why.)
>    - Getting status / success-fail is slightly easier. Still, sometimes
>    an error or warning will appear as a single formatted string to pass to the
>    user, and you cannot decide without parsing the string, if it was a warning
>    or an error.
>
>
> I would say that "tagged output" is your best choice, right now.
>
>    -Jeff Bowles
>
> ps. If you can write in Python or Ruby, the "p4 -G / p4 -R" output (it's
> binary, don't try this without redirecting the output!) is the best
> possibility.  You still have to deal with "was that a success or failure?"
> but the parsing work is far better than anything in ASCII.
>
>
> On Mon, Mar 3, 2008 at 1:14 AM, Ildefonzo Arocha <ilde.web at gmail.com>
> wrote:
>
> > Hello Perforcers,
> >
> > Is it me or does anyone else find that even for the simplest task,
> > scripts have to handle and validate a lot of possible errors/warnings.
> >
> > I am relatively new with Perforce.  In the last months I have been
> > developing some administrative and end-users scripts.  It has been a
> > challange though, no matter what I do, there is always some little
> > detail that makes my scripts fail.
> >
> > On some situations some warnings are sent out as information messages
> > so parsing the output for "error" is not possible, same examples:
> >
> > > p4 -s add -n project.r
> > error: project.r - protected namespace - access denied.
> > exit: 0
> > ==> OK
> >
> > > p4 -s add project.xml
> > error: project.xml - file(s) not in client view.
> > exit: 0
> > ==> OK
> >
> > > p4 -s add -n test.p
> > info: //xp/i2/main/ui/test.p#1 - opened for add
> > info1: //xp/i2/main/ui/test.p - also opened by iar at main
> > exit: 0
> > ==> Not Ok?
> >
> > > p4 -s add test.p
> > info: //xp/i2/main/ui/test.p#1 - currently opened for add
> > exit: 0
> > ==> Not Ok?
> >
> > > p4 -s add -n ui/polylayout/LayoutLL/aadtgend02.lst
> > info: //xp/i2/main/ui/polylayout/LayoutLL/aadtgend02.lst - can't add
> > existing file
> > exit: 0
> > ==> Not Ok?
> >
> > > p4 -s edit -n ui/polylayout/LayoutLL/aadtgend02.lst
> > info: //xp/i2/main/ui/polylayout/LayoutLL/aadtgend02.lst - can't edit
> > exclusive file already opened
> > info1: //xp/i2/main/ui/polylayout/LayoutLL/aadtgend02.lst - also
> > opened by vim at main
> > exit: 0
> > ==> Not OK?
> >
> > > p4 -s sync -n
> > error: File(s) up-to-date.
> > exit: 0
> > ==> Not OK?
> >
> > I have had several different situations, can't remember them all, the
> > most recent had to do with a script the performs a "intergrate -n -b
> > ..." to list all missing revisions from a branch to another.  I
> > inadvertively changed something in the Protection Table, the script
> > then returned no results.  After some digging around I found out that:
> >
> > > p4 -s -c "batch" integrate -n -r -b B_PRA
> > error: No permission for operation on file(s).
> > exit: 0
> > ==> OK, interpret as an error
> >
> > > p4 -s integrate -n -b B_5.01.04 -s "//xp/i2/main/ui/... at 19026, at 19026"
> > error: //xp/i2/main/ui/... at 19026, at 19026 - all revision(s) already
> > integrated.
> > exit: 0
> > ==> Arguably I wouldn't consider this an error, but is this behaviour
> > consistant?
> >
> > This last one is quite contradicting, you can argue that the
> > "integrate" command was not succesful hence "error" but then on the
> > examples above ("p4add" and "p4 edit") the commands are not succesful
> > either, however it outputs "info".
> >
> > Because of this, I have been in the need to send the output of each p4
> > command to some temporal file, analyze it for info messages and error
> > messages and selectively ignore what is error and what is not.  Hard
> > coding error messages in a script is not something I like to do, and
> > since I don't know in advance all possible message combination, I have
> > to do corrections on the scripts upon users feedback.  A major
> > annoyance, not to mention unproductive.
> >
> > Thoughts anyone?
> >
> > Regards,
> > Ildefonzo
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
>
>
>
> --
> ---
> Jeff Bowles - jeff.a.bowles at gmail.com
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com



More information about the perforce-user mailing list