Stream ParentView Examples

This topic shows:

• how to work with the ParentView field and the --parentview option of the p4 streams command
• the effect of converting ParentView: inherit to ParentView: noinherit
  • that in the absence of inheritance, you can still integrate from the parent stream to a child with ParentView: noinherit

Convert a stream to noinherit

1. Create a mainline stream named //streams/product1.
   p4 stream -t mainline //streams/product1
   This opens the editor specified by P4EDITOR, and presents a populated stream spec.

2. Create a development stream named //projectX/bruno-dev as a child of mainline //projectX/main.

   p4 stream -t development -P //projectX/main //projectX/bruno-dev

   This opens the editor specified by P4EDITOR, populated with the stream spec with the Parent and Type fields populated accordingly.

3. For your current client workspace's stream, preview what would happen if the stream were converted to ParentView noinherit, but do not actually perform the conversion or open the stream spec:

   p4 stream parentview -n --noinherit

4. This time, add the -o option to also print a preview of the converted stream spec.

   p4 stream parentview -o -n --noinherit

5. Assuming you already have a pending changelist 1234, perform the conversion for your current client workspace's stream.

   p4 stream parentview -c 1234 --noinherit

   The stream is opened in the current client workspace in the indicated changelist.

6. To make the changes visible to all users, submit the changelist (as you would with any stream spec opened for edit). You can also revert the pending stream spec to abandon the conversion.

Extended example of a conversion to noinherit

The following is an extended example involving several streams to illustrate a conversion.

Assume we have a stream hierarchy The set of parent-to-child relationships between streams in a stream depot. in a stream depot named str with a mainline stream and three development streams:

mainline

Stream: //str/main
Owner: super
Name: main
Parent: none
Type: mainline
Description:
Mainline
Options: allsubmit unlocked toparent fromparent mergedown
ParentView: inherit
Paths:
share ...
Ignored:
*.o

dev1 child

Stream: //str/dev1
Owner: super
Name: dev1
Parent: //str/main
Type: development
Description:
Dev1 child
Options: allsubmit unlocked toparent fromparent mergedown
ParentView: inherit
Paths:
share ...
Remapped:
docs/... product_docs/...

dev2 grandchild

Stream: //str/dev1
Owner: super
Name: dev2
Parent: //str/dev1
Type: development
Description:
Dev2 grandchild
Options: allsubmit unlocked toparent fromparent mergedown
ParentView: inherit
Paths:
share ...
Remapped:
import ssl_libs/... //depot/libs/ssl_libs/v1.0/...

dev3 child of dev2

Stream: //str/dev2
Owner: super
Name: dev3
Parent: //str/dev2
Type: development
Description:
Created by super.
Options: allsubmit unlocked toparent fromparent mergedown
ParentView: inherit
Paths:
share ...

client workspace view of dev3

Because all the streams are ParentView inherit, the client workspace view for workspaces of //str/dev3 is the inherited result of all streams back to the //str/main mainline stream:

Stream: //str/dev3
View:
//str/dev3/... //super_client/...
//depot/libs/ssl/1.0a/... //super_client/ssl_libs/...
//str/dev3/docs/... //super_client/product-docs/...
-//str/...%%1.o //super_client/...%%1.o

The view reflects all that has been inherited:

• The mainline //str/main has an Ignored entry for files ending in *.o
• Its child, //str/dev1, remaps the docs path to a different name, product-docs.
• The next stream, //str/dev2, adds a Paths line to import an SSL library from a non-streams location.
• Finally, //str/dev3 has Paths share ...

converting dev3 to noinherit

A user of stream //str/dev3 converts the stream from ParentView: inherit to ParentView: noinherit, including source comments, and submits the resulting converted spec:

p4 stream parentview --source-comments --noinherit
p4 submt -So -d "Converting dev3 to noinherit"

After conversion:

• the client workspace view for a workspace of //str/dev3 remains unchanged
• the Paths field of //str/dev3 does change:

Stream: //str/dev3
Update: 2020/11/05 11:30:02
Access: 2020/11/05 11:42:21
Owner: super
Name: dev3
Parent: //str/dev2
Type: development
Description:
Created by super.
Options: allsubmit unlocked toparent fromparent mergedown
ParentView: noinherit
Paths:
import ssl_libs/... //depot/libs/ssl/1.0a/... ## merge from //str/dev2@8
share ...
Remapped:
docs/... product-docs/... ## copy from //str/dev1@9
Ignored:
*.o ## copy from //str/main@7

where

• the ParentView field is now noinherit
• The Paths, Ignored and Remapped fields in //str/dev3 have been updated based on the contents of the fields in all ancestor streams
• The comments indicate from which stream the changes originated, and if they were copied or merged into the resulting stream

integrating a stream spec from its parent

Suppose another user modifies the Paths field of //str/dev2 by changing the SSL library version from 1.0a to 1.1.1h:

Paths:
share ...
import ssl_libs/... //depot/libs/ssl/1.1.h/...

Because dev3 was converted to ParentView: noinherit, its client workspace view does not inherit this change and still reflects the original import path of 1.0a.

To make //str/dev3 reflect this change, perform a stream spec integration from its parent, //str/dev2:

p4 integrate -r -As -S //str/dev3

Stream spec //str/dev3@5 - integrate field Paths from //str/dev2@10

Resolve any differences with the p4 resolve command. In this case, the user chooses to accept the changes from //str/dev2 with at, which means "accept theirs":

p4 resolve -So
//str/dev3 Paths - resolving //str/dev2@10
Paths resolve:
at: import ssl_libs/... //depot/libs/ssl/1.1.h/...
ay: import ssl_libs/... //depot/libs/ssl/1.0a/... ## merge from //str/dev2@8
am: merge of both
Accept(a) Skip(s) Help(?) am: at
//str/dev3 Paths - copy from //str/dev2@10

The stream spec is open (for integrate) in the current client workspace, and the user can inspect what the client view would be with the new spec:

View:

//str/dev3/... //super_client/...

//depot/libs/ssl/1.1.h/... //super_client/ssl_libs/...
//str/dev3/docs/... //super_client/product-docs/...
-//str/...%%1.o //super_client/...%%1.o

The client workspace view for the client of //str/dev3 now reflects the change made to the Paths field of stream //str/dev2.

Because //str/dev3 has a noinherit ParentView, no implicit inheritance occurred. Instead, we performed an explicit integration and resolve. To make the changes to //str/dev3 visible to all users, the user submits the pending change. This affects all client workspaces of the //str/dev3 stream.