Anthony Brien
Anthony Brien

Reputation: 6166

How do I setup dev streams that map mainline to a subfolder?

I'm struggling how to setup streams for the following scenario:

I have a library project (//libX) using typical mainline, release and dev streams.

However, I want to have dev streams for separate products (//libX/projectA) that use this library. These products have different directory structures, and I want to map //libX/main/... to a subfolder //libX/projectA/extern/libX/....

For example, my lib is structured like this:

//libX/main
    /bin
    /src
    /tests
    readme.txt

And my projects are something else altogether, but use my lib

//libX/projectA
    /documentation
    /extern
        /libX
            /bin
            /src
            /tests
            readme.txt
        /MaxSDK
    /source
    /tools
    config.xml

The closest I've had it to work was like this:

But the remaps only seem to fix the file locations on the local machine. Using the above remap settings, the libX files end up at the same root as projectA files.

Can the above scenario work with streams or I should go back to branch specs?

Thanks!

Upvotes: 0

Views: 812

Answers (1)

Samwise
Samwise

Reputation: 71562

Your project shouldn't be a child stream of your lib stream -- putting it in its own stream depot seems less confusing:

//libX/main
    /bin
    /src
    /tests
    readme.txt

//libX/projectA    (child of //libX/main)
    /bin
    /src
    /tests
    readme.txt

//projectA/main
    /documentation
    /extern
        /libX      (mirror of //libX/projectA)
            /bin
            /src
            /tests
            readme.txt
        /MaxSDK
    /source
    /tools
    config.xml

And you'd get this structure by doing:

Stream: //projectA/main
Paths:
    share ...
    import extern/libX/... //libX/projectA/...

Unfortunately there are some limitations with this approach -- if your libX Paths aren't a trivial share ... then the import won't pick it up correctly since the import path depotPath syntax imports a depot path, not a stream path. With a normal import you also can't make changes to libX/projectA from within this stream -- you can use import+ to permit this, but I've seen enough problems with import+ that my inclination would be to make this my workflow when changing the library:

p4 switch //libX/projectA
(make changes)
p4 submit
p4 switch //projectA/main

although this assumes that the library is modular enough (with its own unit tests that cover your project's use case etc) that you can do that work in it independently.

Upvotes: 2

Related Questions