[p4] Perforce 2006.1 - Time to upgrade?

Karl Elvis MacRae kmac at apple.com
Fri Jul 21 15:25:43 PDT 2006


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