[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
scripted,
>> 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
>projects/products.
>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.
Keith
More information about the perforce-user
mailing list