Stream views and paths

This section explains how streams work and provides examples. To learn more, see the p4 stream command.

The following explains rules that apply when configuring a stream specification.

Define the view and paths

The Paths, Remapped, and Ignored fields define the stream View. These fields control the files and paths that compose a stream and define how those files are propagated.

• A mainline stream has no parent.
• A sparse stream (sparsedev, sparserel), task stream, or virtual stream always inherits its view from its parent stream.
• A development or release stream can be set to inherit or not inherit from the parent stream.

To modify the structure of the child stream, specify the paths as follows:

Type	Sync?	Submit?	Integrate to/from Parent?	Remarks
share	Y	Y	Y	(Default) For files that are edited and propagated between parent and child streams. All files in a shared path are branched and, in general, shared paths are the least restricted.
isolate	Y	Y	N	For files that must not be propagated outside the stream, but can be edited within it, such as binary build results.
import	Y	N	N	Files in this path are mapped as in the parent stream's view (the default) or to <depot_path> (optional). Such files are accessible to workspaces but cannot be submitted or integrated to the stream. If <view_path> is used, it does not necessarily import files from the parent of the stream it was used on. It imports the view. If the parent stream has a parent (grandparent) and the parent's stream view is shared, files are imported from the grandparent stream. An example would be the virtual child stream created of a release or development parent stream, where files are imported from the mainline grandparent. If depot_path is used for files that must be physically present in the stream but are never changed, such as with third-party libraries, it can include a changelist or automatic label specifier that aliases a changelist to limit the imported files to the revisions at that change or lower. Clients of that stream are limited to seeing revisions at that point in time or lower within that depot path. Use the syntax @changelist# For example: //depot/lib3.0/…​@455678.
import+	Y	Y	N	Similar to an import path because it can reference an explicitly defined depot path, but unlike a standard import path because you can submit changes to the files in an import+ path.
import&	Y	N	N	Similar to an import path, except that multiple import& paths can map a single depot_path to multiple view_path paths. Files marked this way are readonly. The depot_path is required in this format: view_path depot_path This feature does not support graph depots A depot of type graph that is used to store Git repos managed by P4 Server. See also Git Connector and classic depot. Such one-to-many mapping is also called ditto mapping. To learn more, see the Example of ditto mapping for a stream spec in the p4 stream command.
exclude	N	N	N	Files in the parent stream that must never be part of the child stream.

In this example,

Paths:
        share ...
        import src/...
        import lib/...   //depot/lib3.0/...
        isolate db/...

• Files in the src path are not submittable and are imported from the parent stream’s view.

• Files in the lib path are not submittable and are imported from an explicitly-specified location in the depot.

• Files in the db path can be edited and submitted in the stream, but cannot be copied to the parent.

The paths are used to generate the mappings for client workspaces that are associated with the stream. If the stream structure changes, the workspace views are updated automatically and cannot be altered manually. If the stream is locked, only the stream owner, which might be a user or a group, can edit the stream specification.

A stream specification can also:

• Remap file locations so that a file in a specified depot location is synced to a different location in the workspace.

• Screen out files according to file type.

For example, to ensure that object files and executables are not part of the stream, add to the stream specification:

Ignored:
        .o
        .exe

To learn more, see Ignoring groups of files when adding.

Wildcard rules

The use of wildcards is subject to restrictions that are intended to avoid performance issues.

Allowed	Not Allowed	Explanation
isolate readme.*	isolate ....txt	Wildcards not allowed at the root level.
isolate test/....txt Allowed because processing is limited to subdirectories of the test directory.	isolate test.../.txt Not allowed because processing is not limited to subdirectories of any directory.	Embedded wildcards must be after the final directory separator /

Overlay mappings

Stream specs do not allow overlay mapping (+), with the exception of Sparse streams, which always have an overlay mapping.

Example client view of a stream

To derive the client workspace view of a stream view, add //clientname to the second path of the stream spec.

1. In this example, your client workspace is named ws1 and your client workspace is attached to a stream:

   //streamdepot/project1/main

2. A stream path of share ... creates this stream view:

   //streamdepot/project1/main/... ...

3. For the client workspace view, add //ws1 as the prefix to the second part of the stream view:

   //streamdepot/project1/main/... //ws1/...

4. If the client workspace defines the Root directory to be

   /home/maria/source/project1/main

   the mapping from the depot to the local disk is

   //streamdepot/project1/main/... /home/maria/source/project1/main/...

Performance and syncing

Syncing a large stream to a client workspace might take a considerable amount of time to complete. This problem can be addressed by using selective arguments to the p4 sync command or creating Virtual streams. With 2025.1 and later, another way to reduce the time it takes to sync is to filter the view. To learn more, see the LimitView: form field under p4 client.