[p4] Re: Perforce Configurations

Paul Andrei 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 
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.


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.

Paul Andrei




More information about the perforce-user mailing list