[p4] Finding the workspace name: is p4config mandatory?

Ivey, William william_ivey at bmc.com
Mon Feb 25 08:01:10 PST 2008


#1 is true only because P4V is its own environment with the
appropriate settings. You had to make them at some point for
P4V to operate, so making them a second time for a different
environment makes sense.

#2 Nothing prevents that.

#3 Make is the perfect environment to do this. That was our
first method and is still in use seven years later.

> Item #2 implies that I don't just have a problem of setting
> up 1 p4config file for N workspaces on a build server, but
> an NxM problem where M is the number of developers.

No, your problem is creating one, incredibly simple, template
file which the developer renames and modifies once per workspace,
and probably never has to deal with again. All they have to fill
in is the user ID (once for all workspaces) and the client
(which could also be once for all branches if you only have
a single client covering all the branches).

Of course they will have to set P4CONFIG in their environment,
but it's strictly cut and paste from a common prototype. (Put
the instructions in the template file as comments.)

If you don't trust the developers to get that much right, how
did you trust them to install and configure P4V?

-Wm

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Steve M.
Robbins


Hi,

I should clarify a few things.

1) It is perfectly possible to use p4v without setting anything in
the environment.  Not the workspace, not P4PORT, not even P4CONFIG.
This is how we operate today.

2) We typically want developers to be able to build on their machine.

3) The developer build is set off outside of p4v: from an IDE, or
command line "make", etc.


Item #2 implies that I don't just have a problem of setting up 1
p4config file for N workspaces on a build server, but an NxM problem
where M is the number of developers.  (Alternatively, each developer
has to set up N config files.)

Granted, this can be done.  It's not rocket science.  But it gives you
NxM chances to make a mistake while setting up something that should
be mechanically generated (as is done by both CVS and Subversion).
When I get to a point like this I figure either I'm abusing the tool,
or the the tool is too limited.

So what you folks using p4v with large M do?

Thanks,
-Steve

On Fri, Feb 22, 2008 at 09:43:24AM -0600, Steve M. Robbins wrote:
> Hi,
> 
> A recent thread on this list concerns adding a changelist number to
> C++ code, to which Robert Cowham responded with a suggestion to run a
> couple of p4 commands in the root of the workspace [1].  This is easy
> to script, but it assumes that the workspace name is available to the
> script.
> 
> As a build manager, I would prefer to write one script to be used by
> all developers.  Each developer has their own workspace, so the
> workspace name cannot be embedded in the script.  Therefore it seems
> that the script has to obtain it from the environment.  So either you
> have to have it set in the environment (but then who uses just one
> client?) or you have to have a p4config file properly set up.
> 
> Is that the case -- or is there another possibility that I'm
> overlooking?  Is p4config therefore mandatory even for a shop that
> otherwise uses p4v exclusively?
> 
> Now, if p4config is mandatory, is there a way to generate them
> automatically?  I have been crafting each of mine by hand, which is
> a real nuisance.  It strikes me that the first "p4 sync" could write 
> the config file for me.
> 
> Thanks,
> -Steve
> 
> [1]
http://maillist.perforce.com/pipermail/perforce-user/2008-February/02334
2.html
> 



> _______________________________________________
> 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