[p4] multiple automatic labels

[John Shuping]

Greetings, folks.  My first post to the list,
thanks for reading.

In a nutshell our shop is new to Perforce from CVS.
We are working on migrating our huge build process, and
We are interested in syncing to multiple automatic labels
from within a single client workspace.  I have done a lot
of searching and some good ideas were presented about 3 years
ago, in this thread:

http://maillist.perforce.com/pipermail/perforce-user/2003-October/ 
011677.html

These are all really good ideas.
However, we would like to use automatic labels, they are lightweight  
and cool!

Has anyone figured out a good way to do something like that but with  
automatic
labels?

We are doing a fairly basic form of modular software development, as  
far as I can tell.
Our downfall is probably the way in which our code structure needs to  
be set up for
the build and dev process- we have several "library" source code  
trees that need to be in subdirectories
of the big tree of base code, and we want each instance of this (a  
build or developer
environment), to only use a single client workspace.

We have a text file dictionary in the big base tree
that says which modules we need in which subdirectory and at what  
label they need
to be synced to.  *Each being synced to a different label is the  
other catch :)*

In essence, our view is:

//prod/main/big_code_tree/... //client/...
//prod/main/foo_lib/...    //client/third_party/foo_lib/...
<many more submodules>

For builds and freshly made developer environments, we need
foo_lib to be synced to some label, which is defined in that text  
dictionary.
With CVS, we check out the big base tree, and its Makefile
calls an in-tree utility "co_helper", which parses the dictionary and  
checks
out the submodules like foo_lib with the appropriate -r argument.

I'm sure the best approach is to make these submodules into  
formalized binary package
releases and stop this madness, but we aren't there yet.

What we ideally were hoping was that automatic labels would support  
multiple
revision specifiers, one per View line, ala:

//prod/main/big_code_tree/... at 123456
//prod/main/foo_lib/... at foolabel-123

If this were possible, we could do away with our own dictionary file  
because the label
then represents both view and revision for us.  Can anyone explain  
why Perforce
couldn't do this, in terms of technical feasibility?  (We sent in a  
feature request :)

Since we are on a tight schedule, we are instead looking at the
most direct replacement of CVS with Perforce, continuing to use our  
text file
dictionary.  Due to the large # of submodules and developers we would  
like to
be able to only use one client workspace for each build and/or  
developer environment.

It looks like we'll use our co_helper util will parse the dictionary,  
and for each module,
add a line to the client View and then 'p4 sync ./ 
foo_lib/... at somelabel'.

There are 2 downsides to this approach, that we foresee:
- Users can run cvs up at the top level and this will update their  
base code to HEAD
and each of their submodules to whatever rev it is checked out at  
(CVS/Tag file).
Running 'p4 sync' at the top level will effectively mess up the  
submodules that
were synced to labels.  We can get around this with training.
- Users wanting to update only their big  base code (not the  
submodules), have to type 'p4 sync //prod/main/big_code_tree/...' to  
avoid hurting their submodule checkouts.
We can get around this by having co_helper do this step for users  
easily.

Any ideas or similar scenarios to consider?
Am I using Perforce in the completely wrong way? :)

We also considered using a release branch for each release of each  
module, but
that would be *several* per day, and p4 protect overhead to lock down  
each branch.
We need every single build to be perfectly reproducible (so every  
submodule
needs to be labelled or have its change # saved on record).

Thanks!
John