0

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:

  • Paths: share ...
  • Remaps: ... extern/libX/...

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!

Anthony Brien
  • 6,106
  • 7
  • 43
  • 56
  • You'll need to expand your example a little bit -- what other files are "intermingled" with the libX files? Where do they come from? Where are they supposed to go? – Samwise Mar 05 '17 at 18:58
  • The 'import' or 'import+' options may help you, but it is hard to say for sure without knowing answers to the questions that Sam asked. – P4Jen Mar 06 '17 at 10:43

1 Answers1

2

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.

Samwise
  • 68,105
  • 3
  • 30
  • 44
  • Yeah I think I'll keep streams for the lib's main, release and dev branches, but for the client projects, I'll stick to regular branch specs. It'll be simpler that way. The reason I was trying to do all this was to see which project had changes not yet integrated into my library (through the stream graph colored arrows). – Anthony Brien Mar 06 '17 at 19:53
  • 1
    Ah -- so what you're actually after is making per-project changes to the library! The missing word in your original question was "modify". :) I'll substantially revise my answer in a sec. – Samwise Mar 07 '17 at 19:03
  • Yes, each project could be making changes to the library, and I wanted the support of streams to help me detect these changes to know when I have code to integrate back into the mainline. – Anthony Brien Mar 07 '17 at 23:07
  • 1
    Yeah, streams aren't really designed to handle component-based development unfortunately -- there are some hacks around it (there are some blog posts and I think some scripts in the p4 open source workshop) but the native support is all geared toward tracking lifecycles of a single component rather than assembling multiple components into one larger thing. I think for now setting it up the way I describe (letting streams handle the variants but manually setting up imports to describe the component relationships) is the best way to go. – Samwise Mar 08 '17 at 00:14