[p4] Re: Perforce Configurations
pandrei at foliage.com
Mon Mar 21 10:28:00 PST 2005
kgraham at uasc-id.com wrote:
> Paul Andrei wrote:
> configuration-through-integration v.s. server-side symbolic links
>>2. CTI is more labor intensive than symbolic links (one
>> actually has to integrate the common components in all
>> their client projects). On the other side, an SSSL could be
>> represented as a one-line text file of a new Perforce type:
>> easy to create and update.
> 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
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.
2. The main advantage that configuration-through-integration has is that
it provides a private copy/branch for the client/consumer projects so
they can make custom changes (bug-fixes or not). But if the copy was
modified, the mechanic centralized update script would not be able to
handle the conflicts: the update has to be manual.
Note that server-side symbolic links cannot be used in this situation at
all: they are not silver bullets. :-)
>>3. CTI consumes many Perforce server resources (metadata and
>>depot disc space) while SSSL wouldn't consume any (except for
>>a small file in each client project).
> Because of lazy integration, all that is consumed is a bit of metadata. No
> depot space is consumed.
That's true for the first integration. What about the subsequent
integrations, when you put [potentially significantly updated] versions
on top of the older ones? I'm not sure, but I don't think it keeps being
lazy integration at that point.
More information about the perforce-user