[p4] Re: Perforce Configurations

Paul Andrei pandrei at foliage.com
Mon Mar 21 14:14:49 PST 2005


kgraham at uasc-id.com wrote:
> I completely agree that a "pull" mechanism makes more sense, and, using
> Perforce, I'd build it into the client spec
> (//depot/component/release1.4.0/...), using integrations (as described), or
> make it part of the build system.  (i.e. reference the correct "system"
> directory containing the version of the component required.)


Conceptually, the clientspecs sit at the border between Perforce and 
user workspaces. There is one clientspec per user workspace, and they 
cannot be [easily] shared by the team members. Putting configuration 
information in the clientspec requires you to keep them in sync with the 
configuration changes. For example, replacing
     //depot/component/release1.4.0/...
with
     //depot/component/release1.4.1/...
require you to change all client specs simultaneously. Needless to say, 
this is error-prone. In addition, how are you going to remember a year 
from now what versions of the third party libraries or common assets you 
used to build a certain version of a product? Do you export the 
clientspec form into a text file and include it with the release notes?

Same goes for the build scripts. They are even more removed from 
Perforce than clientspecs. What if the users prefer to use an IDE 
instead of build scripts? The IDE will use the clientspec directly 
through P4SCC. On the other hand, the build scripts can be checked in 
and versioned by Perforce, while the clientspecs can't.

The configuration information for a project/product is global, and 
should be specified in one place only (what I call 
single-point-of-change principle, probably there are better names for it 
out there).


> Unfortunately, I would expect symbolic links to be used by many people to
> implement the "shared folders" (aka jello views) mechanism of VSS.  i.e. a
> *push* mechanism.  I was just pointing out that if you REALLY want, you can
> implement a push mechanism in Perforce with very little pain.  At least, the
> tool doesn't inflict much pain in a push mechanism; you'll probably be
> inflicting quite a bit on yourself.


Well, some users are perfectly capable of messing up their development 
process with the existing Perforce mechanisms anyway ;-).

---------<>---------

Server-side symbolic links (SSSL) to *frozen* versions of reusable 
components are in almost all respects equivalent to CTI 
(configuration-through-integration). Were they differ is this:

1. An SSSL is lightweight (potentially less costly to the Perforce server).

2. An SSSL explicitly states what version of the common asset was 
included in the project. With CTI one has to inspect the change history.

3. CTI provides a place to create temporary short-lived variants 
(bug-fixes or not). This is something to avoid in a component release 
model, as was pointed out.

---------<>---------

Server-side symbolic links (SSSL) to *unfrozen* (floating?) versions 
have been spoken against off on this forum because of their potential 
for being misused. Well, many things in life can be misused but we still 
create them because we have *some* good use for them.

In our case we were very interested in SSSL to unfrozen versions to help 
in our transition from two monolithic applications (code developed in 
the last 15 years that up to 5 years ago was common) to a 
component-based internal release model. After the common assets are 
factored out, unit/component tested, with stable releases distributed 
internally, we would replace the *SSSL to unfrozen versions* with *SSSL 
to frozen versions*.


> And provided you have a system-wide "scripts" folder, it would not be
> difficult to provide a tool or command-line "selective pull" mechanism as
> well, if "integrate, accept all, submit" is too error-prone for an average
> perforce user.


Since server-side symbolic links are not available, we have created a 
tool called p4cm (Perforce Configuration Manager) on top of P4API that 
reads the configuration information from a .p4c (Perforce Configuration) 
XML file, creates the clientspec, fetches the code, and computes the 
"actualized" .p4c *frozen* configuration that corresponds to the code 
that was just fetched (finds out what was the last submitted change 
number for each unfrozen component).

Afterwards, for the daily work, the developers use the clientspecs that 
were automatically created.

We keep these .p4c files in Perforce too: global, shared, safe, and 
versioned. In P4Win, it's enough to double-click on a .p4c file revision 
in order to launch the p4cm tool.

We just started using p4cm for our development. I will report back to 
the community when we will accumulate enough information about how 
useful this strategy really is.

Paul Andrei





More information about the perforce-user mailing list