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

Jamie.Echlin at barclayscapital.com Jamie.Echlin at barclayscapital.com
Fri Aug 10 08:05:18 PDT 2007


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