[p4] multiple automatic labels

[Robert Cowham]

Hi John

Probably the easiest way is to use branching of modules so that people are
just syncing to one thing, otherwise as you point out, there is the risk
they sync the wrong part to something else.

Do you really need to worry about p4 protect every day??

With good naming conventions and repository structure, I suspect you could
get away with something similar (including a good trigger or two if
appropriate).

Dynamic labels are great, but they are only a start as you can see. I too
would like the extra level of Revision per view line (also for them to show
up in the output of "p4 labels <file path>", at least for the case where
single changelists are used - just a single extra lookup).
 
Don't forget spec depots to automatically save all versions of spec objects
including labels, client workspaces etc.

Regards
Robert

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of John Shuping
> Sent: 06 February 2007 16:30
> To: perforce-user at perforce.com
> Subject: [p4] multiple automatic labels
> 
> 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