[p4] Re: Perforce Configurations
pandrei at foliage.com
Mon Mar 21 21:47:06 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.
We aren't claiming any credit for CTI. We realized that it was very
probable that other people have invented and reinvented it before. If
Laura Wingerd and Chris Seiwald are the first on record with this
strategy, by all means, we should give them credit.
> I like
> it because it sidesteps a lot of "forget the build configuration"
> mistakes that other strategies - including some symlink strategies - use.
The server-side symbolic links (or Perforce depot symbolic links) that I
suggested are not filesystem symbolic links (Unix style or Windows NTFS
reparse points). Those would create the jello views that everyone hates.
"A file in your workspace should not change unless you explicitly cause
the change." [High-level Best Practices in Software Configuration
Management, by Laura Wingerd and Chris Seiwald].
What I suggested are symbolic links in the Perforce depot namespace, or
symbolic links (references) in the metadata. As a practical way of
implementing them, I suggested one-line text file with a new Perforce
filetype, for example "reference". On sync, when Perforce encounters one
of these references, instead of fetching the small file it would open
it, read the one line path, and then fetch the referenced component and
version. The final effect of this process would be assembling a complete
product from frozen and unfrozen components.
We can obtain the exact same effect today by using clientspec views
*and* fetch scripts (to specify the frozen versions). But disseminating
new configuration information among the team members, and making
everyone update their clientspecs/scripts is error prone.
More information about the perforce-user