[p4] Re: Perforce Configurations

[Paul Andrei]

Andreas Axelsson wrote:
> Wouldn't the problem below be solved with an extra client spec for
> ProductX?

> I know there's no way to make a clientspec map to a specific revision of
> a file or hierarchy, like @label_001 below suggests, and that's
> something I too could wish for, but the actual mapping of components
> from depot to ProductX in this case, would work just fine with a client
> spec. If you got your team to use a script when syncing instead of
> running p4 sync //... you could add the label part there.
> 
> Example client:
> //depot/Component1/main/... //client/ProductX/Component1/...
> //depot/Component2/branchC/... //client/ProductX/Component2/...


In order to completely specify a file/component version in Perforce, one 
has to provide its space-time coordinates: the depot path is the 
location (space coordinate) while the revision/change/label is the time 
coordinate.

The Perforce clientspecs are purely space mappings. They cannot provide 
any time information. That has to come from some form of executable script.

So right now, the configuration information has to be split between 
clientspecs and executable scripts. Imagine now a team of 50 people 
simultaneously working on 10 configurations. It takes discipline and 
effort from everyone to stay up-to-date. A solution built into Perforce 
is preferable.


> So what's really missing is a way to lock a clientspec to a given
> revision, right?


Yes and no. Yes because it's an important missing feature. No because 
it's not enough. Another missing piece is the capability to seamlessly 
store, version, and share configuration information through Perforce.

Using clientspecs as the main source of configuration information is not 
  appropriate. Clientspecs are local, specific to a user/workspace, and 
not easily shared among team members, while the configuration 
information is global, and associated with a codeline/branch/product. 
This disconnect is significant.


>>But the ideal solution, and this a suggestion to Perforce, if 
>>they are monitoring this forum, is to implement some kind of 
>>symbolic links in the Perforce depots themselves.
>>
>>Take this structure, for example:
>>
>>|    //depot/Component1/main
>>|           /          /branchA
>>|           /          /branchB
>>|           /
>>|           /Component2/main
>>|           /          /branchC
>>|           /
>>|           
>>/ProductX/Component1{//depot/Component1/main/... at label_001}
>>|                    /Component2{//depot/Component2/branchC/...}
>>|                    /Module1
>>|                    /Module2
>>
>>The notation
>>
>>     Component1{//depot/Component1/main/... at label_001}
>>
>>denotes a Perforce depot symbolic link (PDSL) to a frozen 
>>version of Component1, while
>>
>>     Component2{//depot/Component2/branchC/...}
>>
>>denotes a PDSL to the tip of Component2 branchC.
>>
>>Of course, all Perforce commands would need to be updated to 
>>follow these links when necessary.
>>
>>   -Paul Andrei