[p4] Perforce 2006.1 - Time to upgrade?

Russell C. Jackson rusty at rcjacksonconsulting.com
Fri Jul 21 16:06:24 PDT 2006


Yes, those are ones that they said it would complain about. I think they 
made an assumption that not very many people would be doing this. I 
think the behavior should be to warn about these mappings, but not to 
fail to work.

Thanks,
Rusty

--------------------------------------------------
RCJackson Consulting
Perforce Consulting Partner and Certified Trainer
--------------------------------------------------
Russell C. Jackson
211 River Oaks Lane
Russellville, AR 72802
--------------------------------------------------
rusty at rcjacksonconsulting.com
http://www.rcjacksonconsulting.com
tel:      479-696-9710
fax:      479-967-0963
mobile:   479-747-3845
--------------------------------------------------




Karl Elvis MacRae wrote:
> On Fri, Jul 21, 2006 at 03:03:23PM -0700, Russell C. Jackson may have typed these words: 
>   
>> Can you give an example of some of your mappings that it complained about?
>>     
>
> Yeah  - and understood these are ugly mappings; we're working on better ways to do this. We have an issue in that we're managing data that comes out of a very structured application (cadence) so we can't move stuff around. So we're having to map just certain parts of a tree such that user who need to see it can, users who don't need to see it can't. 
>
> But that aside, each of these are legal mappings in 2006.1 (if they're not, 'p4 client' or 'p4 branch' error out). They just combine to make something illegal; it works in 2005.2, but rather than just a warning, p4 refuses to integ with these . 
>
>
> Here's a client view:
>
> View:                                                                                                                                                                                                              
>         //depot/projectName/...ps_files/....pdf //kmac_1662_projectName.Ecad/projectName/...ps_files/....pdf
>         //depot/projectName/...cdssite/... //kmac_1662_projectName.Ecad/projectName/...cdssite/...
>         //depot/projectName/....cpm //kmac_1662_projectName.Ecad/projectName/....cpm
>         //depot/projectName/....relbrd* //kmac_1662_projectName.Ecad/projectName/....relbrd* 
>         //depot/projectName/...projectInfo //kmac_1662_projectName.Ecad/projectName/...projectInfo
>         //depot/projectName/...worklib/.../packaged/... //kmac_1662_projectName.Ecad/projectName/...worklib/.../packaged/...
>         //depot/projectName/...worklib/.../physical/... //kmac_1662_projectName.Ecad/projectName/...worklib/.../physical/...
>         //depot/projectName/cdssite/... //kmac_1662_projectName.Ecad/projectName/cdssite/..
>         -//depot/projectName/...allegro.jrl* //kmac_1662_projectName.Ecad/projectName/...allegro.jrl*
>         -//depot/projectName/...devices.dml* //kmac_1662_projectName.Ecad/projectName/...devices.dml*
>
>
> Here's the branch spec:
>
>     //depot/projectName/mlb/worklib/.../physical/xxx-yyyy.brd  //depot/projectName/mlb_proto3/worklib/.../physical/xxx-yyyy.brd
>     //depot/projectName/mlb/worklib/.../physical/rule/...   //depot/projectName/mlb_proto3/worklib/.../physical/rule/... 
> 	//depot/projectName/mlb/worklib/.../physical/valor/xxx-yyyy-dv/pp/....txt //depot/projectName/mlb_proto3/worklib/.../physical/valor/xxx-yyyy-dv/pp/....txt
>
>     //depot/projectName/mlb/worklib/.../physical/valor/xxx-yyyy-dv/pp/....out  //depot/projectName/mlb_proto3/worklib/.../physical/valor/xxx-yyyy-dv/pp/....out
>     //depot/projectName/mlb/worklib/.../physical/valor/xxx-yyyy-dv/odb/....tgz  //depot/projectName/mlb_proto3/worklib/.../physical/valor/xxx-yyyy-dv/odb/....tgz
>
>
> What concerns me is that there's no way to detect that before an upgrade, and perforce don't have a mapping checker they can run on the whole database to insure legality in all cases. Thus they broke a piece of functionality. The fact that I *should not* do what I'm doing doesn't mean it's ok to break it when it's worng in 2005.2. 
>
> --Karl
>
>
>
>
>
>   



More information about the perforce-user mailing list