[p4] Re: Perforce Configurations
johan.nilsson at esrange.ssc.se
Tue Mar 22 00:15:54 PST 2005
> -----Original Message-----
> From: Paul Andrei [mailto:pandrei at foliage.com]
> Sent: den 21 mars 2005 16:13
> To: Johan Nilsson
> Cc: karish at well.com; perforce-user at perforce.com
> Subject: Re: [p4] Re: Perforce Configurations
> 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.
Yes, I only wanted to discuss Chuck's comment, that IUC said that using
symlinks with labels/changelists/whatever made it harder to get bugfixes
for that dependency.
> 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
That's probably what I'd be using most of the time. However, when
working in the mainline it might be even better to map the dependencies
to their (non-frozen) release branches instead to always get the latest
> The server-side symbolic links (SSSL) wouldn't be appropriate
> all the time. They would be just another tool at our disposal.
True. Nobody would be forced to use them unless they'd like to. I don't
know if this is more of an "religious" (quotes really, really
emphasized) issue for Perforce, kind of like the $log$ stuff. Or perhaps
an architectural issue, who knows?
The same would go for the ability to use revision specifications in e.g.
Did you submit a feature request yet to Perforce Support?
> 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.
With reference to do "bug-fixes in different incompatible unshareable
ways", this is hopefully a less common and probably also a much less
desirable way to use CTI. If bugs are detected they should be fixed in
the components' own release branch, reintegrated to the clients using it
(through CTI), and also integrated back into the mainline (all this
assuming there _are_ mainline + release branches).
Isn't CTI just a (perhaps smart) way of using IFB in a way it wasn't
really intended to from the beginning?
> 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.
Basically agreed. Did you put this suggestion in your feature request?
> 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).
As someone else mentioned, depot disc space consumption should be
virtually zero unless modifications are actually made.
Best regards // Johan
More information about the perforce-user