[p4] Re: Perforce Configurations

kgraham at uasc-id.com kgraham at uasc-id.com
Mon Mar 21 10:49:14 PST 2005

> Paul Andrei wrote

kgraham at uasc-id.com wrote:

>> If there are no changes in the destination, the integration can be
>> and essentially requires no labor.  Run a script that does a forced
>> integration into the 5 or 50 targets and checks in the changelist.

>Two problems with that approach:
>1. I would argue that the decision to switch to a newer version of a 
>common component lies with the teams that maintain the client/consumer 
>projects. They should *pull*, based on the needs they perceive, the 
>right version of the reusable components. The centralized script that 
>you mentioned, would *push* the new version into all client/consumer 

>A simple and convenient pull method is preferable, and server-side 
>symbolic links would provide that: the update will consist in changing 
>the link (one-line text file, or a linkspec) and then resyncing to it.

>The script approach is "easy" only because it's centralized and possibly 
>written and run by an experienced Perforce [super]user. Not necessarily 
>but most probably.

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.)

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.

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.


More information about the perforce-user mailing list