List Info

Thread: Upgrade to Perforce 2007.2




Upgrade to Perforce 2007.2
country flaguser name
United States
2007-07-24 07:34:30
To All,
 
Recent messages here have got me worried that I may have jumped the gun when I upgraded our Perforce installation from 2006.1 to 2007.2. In the process, I forgot about my P4Perl installation used by my build system and admin scripts. I have the following installed:
  • Perforce P4D 2007.2
  • P4API: Release 2005 2, PatchLevel = 93627, SuppUpdate = 2006 02 14
  • P4Perl 3.4804
Do I need to do anything, or will these still work with basic operation on 2007.2?
 
Thanks...
Scott Lavender | SCM Specialist | Visiprise | office: 770.619.4166 | www.visiprise.com
 

It is our company policy not to accept email of any data controlled by the International Traffic in Arms Regulations (ITAR). Please direct inquiries to ITARvisiprise.com">ITARvisiprise.com for instructions and authorization to transmit such data.

 
Re: Upgrade to Perforce 2007.2
country flaguser name
United Kingdom
2007-07-24 08:04:16
Hi Scott,

> Recent messages here have got me worried that I may
have jumped the gun
> when I upgraded our Perforce installation from 2006.1
to 2007.2. In the
> process, I forgot about my P4Perl installation used by
my build system and
> admin scripts. I have the following installed:
>
> *	Perforce P4D 2007.2
> *	P4API: Release 2005 2, PatchLevel = 93627, SuppUpdate
= 2006 02 14
> *	P4Perl 3.4804
>
> Do I need to do anything, or will these still work with
basic operation on
> 2007.2?

You'll be fine - the 2007.2 server is backwards compatible
with older clients. 

There have been issues in the past where scripts have broken
because newer 
versions of the server support tagged output for commands
that didn't 
previously enjoy that luxury. In versions of P4Perl since
3.5313, 
calling '$p4->SetApiLevel( <integer> )' (where
<integer>' is the client 
protocol level) protects you from that. 

So, for example, if a particular script was written with the
2006.1 API, you 
could guarantee it would work when executed with the 2006.2
or 2007.2 APIs, 
and against a 2007.2 server by calling:

	$p4->SetApiLevel( 59 );

Doing this is a generally good idea, and I recommend you do
it for all 
scripts, as you write them. To find out the protocol level
for any given 
version of P4, run:

	p4 -vrpc=3 info

Then look for the value of the 'client' variable in the
'protocol' send buffer 
at the top of the output. So, here's an example for a 2006.1
p4:

RpcSendBuffer cmpfile =
RpcSendBuffer client = 59   <------ THIS IS WHAT YOU'RE
AFTER
RpcSendBuffer api = 99999
RpcSendBuffer func = protocol
Rpc invoking protocol
RpcSendBuffer prog = p4
RpcSendBuffer version = 2006.1/LINUX26X86/104454
RpcSendBuffer client = barney
RpcSendBuffer cwd = /home/tony
RpcSendBuffer host = barney.perforce.co.uk
RpcSendBuffer os = UNIX
RpcSendBuffer user = tony
RpcSendBuffer func = user-info
...

Setting the API level prevents the server from sending the
client output in a 
form that would not have been expected at the time that
client was released: 
so non-tagged output will be produced if non-tagged output
is what a 2006.1 
client would expect.

Note: normally, the P4 command-line client sets its API
level to 99999 as you 
can see above; the idea is that the P4 command line doesn't
need to parse the 
output from the server, just report it to the user (it's the
user who parses 
it), so it can accept output in the latest form that the
server can offer it. 
Scripts and other API-based programs that parse the output
of commands don't 
have that luxury, and the API level exists to help them.

To see the effects for yourself, try these two commands
against a recent 
server:

	p4 -Ztag depots
        p4 -Ztag -Zapi=57 depots

Hope that helps!

Tony
_______________________________________________
p4perl mailing list
p4perlperforce.com

http://maillist.perforce.com/mailman/listinfo/p4perl

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )