[p4] multiple automatic labels

[Slava Imeshev]

I think I would be able to suggest something to handle 
this and we actually have some customers doing something 
similar, but I don't think it is a good idea.

What you seem to have have is a source-level inter-module 
dependency, when a module needs other's module code in a 
given state to be built. This is not a good thing for 
a simple reason - any module can break your build w/o 
knowing it.

IMHO there are only two real solutions to this problem.
Both of them require biting the bullet and fixing the 
issue once and forever.

#1. Treat dependencies as first-class 3-rd party objects.
This means they are a) unchangeable b) follow normal
upgrade process: update, test locally, check in, lock.

#2. If your dependency modules are highly volatile, it 
is possible they were moved out too early. Merge them
back into the mainline and let evolve being just a part
of the product.

The side effect of this is that you won't need strange
arrangements for depot views and your engineers will 
be doing simple

  p4 sync //prod/main/... at release_build

HTH

Regards,

Slava Imeshev
www.viewtier.com


--- John Shuping <john at librum.org> wrote:

> 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
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> 
>