[p4] Re: Perforce Configurations

Paul Andrei pandrei at foliage.com
Mon Mar 21 07:13:19 PST 2005

Johan Nilsson wrote:
> Would it make a difference making the symbolic link point to a
> dependency release branch instead (e.g.
> //depot/common/superlib/rel/1_1/...)? OTOH, that could make updates (bug
> fixes) get into your project without you really wanting it (or perhaps
> without even being aware of it).

If the symbolic link was defined to point to a non-frozen version (the 
head of //depot/common/superlib/rel/1_1/..., for example), then yes, you 
expect to get into your project all changes that occur at the tip of 
that branch. Maybe that's what you want, and it's useful sometimes.

To prevent that, the symbolic link could point to a frozen version instead:

     //depot/common/superlib/rel/1_1/... at change
     //depot/common/superlib/rel/1_1/... at label

The server-side symbolic links (SSSL) wouldn't be appropriate all the 
time. They would be just another tool at our disposal.

The method that Jeff Bowles described on March 17 2005, which I like to 
call configuration-through-integration (CTI), is more appropriate some 
other times.

configuration-through-integration v.s. server-side symbolic links

1. CTI is more appropriate when common components "consumed" by several 
products need to change (bug-fixes) in different incompatible 
un-sharable ways for different projects. In all other cases, server-side 
symbolic links would work just fine.

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.

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


Paul Andrei

More information about the perforce-user mailing list