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).
Cheers,
Paul Andrei