[p4] Re: Perforce Configurations

Paul Andrei pandrei at foliage.com
Mon Mar 21 21:47:06 PST 2005


jab wrote:
> 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.

Paul Andrei




More information about the perforce-user mailing list