[p4] Re: Perforce Configurations
jab at pobox.com
Mon Mar 21 11:43:59 PST 2005
First things first: I like putting a name on this, and "CTI" works as
well as any. Be sure to credit Laura Wingerd and Chris Seiwald with
this strategy, because it's really something that they came up with. I
like it because it sidesteps a lot of "forget the build configuration"
mistakes that other strategies - including some symlink strategies -
And by-hand patching of components is almost always a bad idea.
Now, to the other stuff...
On Mar 21, 2005, at 10:28 AM, Paul Andrei wrote:
> 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
Nah, not if the person who runs the script is YOUR TEAM's project lead
The key is that it's done in a consistent way, and that there are
provisions for recreating how it was done when you decide you need
component XYZ 1.2.2 instead of 1.2.1.
> 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.
My concern is that I want to know what was being built against,
yesterday, or last week, or on the 19th of January, or the last time
that the swallows flew back to Capistrano.
> 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.
No, because it's centralized the strategy and was written by an
experienced person. You can have anyone run it, but it really should
be "the person who tried out those new components in his/her workspace
to make sure they pass regressions." That is someone from your
development team, usually.
> 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.
That's a different problem. If you modify the descendant/derivative
copy, for a bug fix, then you need to own the process of getting that
back to the original group. Better is to get them to reissue that
component with the bug, fixed.
> Note that server-side symbolic links cannot be used in this situation
> at all: they are not silver bullets.
not only are symbolic links *NOT* silver bullets, but often, they're
workarounds that introduce an unstable environment into software
development. VSS "shared folders/files" feels so nice, until you
realize that your checkin just made three already-released products
change behavior. Stability counts for more than just "nifty behavior".
>>> 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.
Most new version upgrades - nearly everything like that - should be a
lazy-copy import. Nothing more. At least for this component-ware
More information about the perforce-user