[p4] Re: Perforce Configurations

Bennett, Patrick Patrick.Bennett at inin.com
Tue Mar 22 07:42:59 PST 2005


> -----Original Message-----
> From: perforce-user-bounces at perforce.com [mailto:perforce-user-
> bounces at perforce.com] On Behalf Of Paul Andrei
> Sent: Tuesday, March 22, 2005 12:47 AM

> We can obtain the exact same effect today by using clientspec views
> *and* fetch scripts (to specify the frozen versions). But
disseminating
> new configuration information among the team members, and making
> everyone update their clientspecs/scripts is error prone.

Our scripts check their version against the head revision (of a key
file) in the depot each time they're run to verify that the user is
running the latest version.  Users can either run the scripts from a
network share (which auto-updates itself when the scripts are changes),
or for performance they can sync them locally and add them to their
path.  If they run them locally, they're expected to add a Review: entry
to their user form so they can be notified of changes and resync them.
If they don't resync, the scripts will belch the next time they run
them.

If they don't use the scripts (everything goes through our 'p' wrapper -
they have to use p for everything instead of p4), then their code will
never get officially built, so there are some 'process' requirements for
them to use the scripts.  :)

The 'p' wrapper has worked very well for us.  p help commands shows all
of perforce's commands (pass-through) followed by our 'extensions'.  p
help xxx on an existing command shows p4's existing help, followed by
our extensions to that command.

As for the clientspec views issue, we have a master script file that
defines all 'codebases' and their relationships.  The scripts use that
on submission (and other commands) to let the user automatically
'propagate' their code to subsequent revisions in the codebase version
line. So if they're putting a hotfix in, say, 1.0 then when they submit
their code they can have the fix automatically propagated from 1.0 to
1.1 to 1.2, to 2.0, etc.

We don't use version #'s for our codebases though as version #'s are
really more of a marketing issue and can frequently change.  We instead
use codenames, or more specifically, colors, since they're easy to
remember and don't convey any particular meaning.

Patrick Bennett





More information about the perforce-user mailing list