[p4] P4::ParseSpec question from p4 perl api

Shawn Hladky p4shawn at gmail.com
Fri Aug 10 08:19:20 PDT 2007

Maybe it could be done w/ p4 spec.  Or, this just occurred to me, why not
have specdef available as an expandable variable within p4 triggers and
avoid the server call altogether.

On 8/10/07, Jamie.Echlin at barclayscapital.com <
Jamie.Echlin at barclayscapital.com> wrote:
>  Thanks Shawn. Tony actually mailed me off list, and after balling me out
> for pasting my question to the wrong list ;-) he said pretty much exactly
> what you said, and explained how to avoid the recursion which was to set up
> a permanent workspace and prevent the trigger from running in that
> workspace. Not mad about that solution though, someone could delete the
> workspace and prevent everyone from updating their workspaces.
> I understand the need to know the specdef in order to parse the form, but
> could that not be found out by running p4 specdef client and parsing that?
> We don't have ruby on our servers, but i'll take a look at the logic for
> that anyway.
> thanks again shawn.
>  ------------------------------
> *From:* Shawn Hladky [mailto:p4shawn at gmail.com]
> *Sent:* 10 August 2007 15:43
> *To:* Echlin, Jamie: IT (LDN)
> *Cc:* perforce-user at perforce.com
> *Subject:* Re: [p4] P4::ParseSpec question from p4 perl api
> I'm not too familiar with the Perl API, but I do understand how the
> underlying C++ API works.  The fundamental problem is that in order to parse
> the form the API needs to know the "specdef", which is a formatted string
> defining the fields and acceptable values in a form.  The specdef may differ
> from server to server... in the case of a client spec, it differs between a
> server at version 2006.2 and 2007.2 to support the new unchanged file
> options.  In the case of jobs, the specdef will vary based on the job spec
> defined by the admin.  So the Perl API is likely running a 'p4 client'
> behind the scenes in order to fetch the server's exact specdef which it then
> uses to parse the form.  That's where you're recursion problem is coming
> from.  The way you have your trigger setup, it may not be possible to know
> if it's in the context of a real 'p4 client' or the fake one called by the
> API to get the specdef.
> But, your best bet is to not write a single line of code.  Courtesy of
> Tony Smith, the following technologies will do what you need and more.  It's
> a trigger written in Ruby that will default your client spec to any
> specified client template.  It will default any options you want and a
> specific view if you so desire.  And it knows how to escape the recursion
> problem.  I'm no Ruby guy, and I got all this up and running in a couple
> hours... and I even added logic that defaults the client only if a user is
> in a specific group.
> Install Ruby
> Install P4Ruby
> http://public.perforce.com/guest/tony_smith/perforce/API/Ruby/index.html
> Get the trigger code from the Perforce public depot:
> //guest/tony_smith/perforce/P4Rubylib/triggers/...
> And look at the comments in defaultclient.rb.
> On 8/10/07, Jamie.Echlin at barclayscapital.com <
> Jamie.Echlin at barclayscapital.com> wrote:
> >
> > Hi,
> >
> > I am writing a form-out trigger on "client", because I want to default
> > new clients to the revertunchanged option (anything other than the
> > submit unchanged option really).
> >
> > Trigger looks like:
> >         ClientOut form-out client "perl \blah\ClientFormOut.pl
> > %formfile% %serverport%"
> >
> > So I open and read the formfile in the trigger, great. Now, instead of
> > just do a plain substitution on the file (just in case SubmitOptions is
> > the user name or something - I know it's not likely but I have other
> > triggers), I want to convert it to a hash. So I call
> >
> > $p4->ParseSpec("client", $form);
> >
> > ($form is the string containing the contents of the formfile). However
> > this starts infinite recursion because it runs client -o. Maybe I am
> > missing something in ParseSpec, according to the docs it should just
> > convert a string to a hash, no need to run a perforce command at all?
> >
> > Cheers, jamie
> >
> >
> >
> > ------------------------------------------------------------------------
> > For important statutory and regulatory disclosures and more information
> > about Barclays Capital, please visit our web site at
> > http://www.barcap.com.
> >
> > Internet communications are not secure and therefore the Barclays Group
> > does not accept legal responsibility for the contents of this
> > message.  Although the Barclays Group operates anti-virus programmes, it
> > does not accept responsibility for any damage whatsoever that is caused by
> > viruses being passed.  Any views or opinions presented are solely those of
> > the author and do not necessarily represent those of the Barclays
> > Group.  Replies to this email may be monitored by the Barclays Group for
> > operational or business reasons.
> >
> > Barclays Capital is the investment banking division of Barclays Bank
> > PLC, a company registered in England (number 1026167) with its registered
> > office at 1 Churchill Place, London, E14 5HP. This email may relate to or be
> > sent from other members of the Barclays Group.
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >

More information about the perforce-user mailing list