Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 CLI Documentation | 2025.2

# p4 stream

Create, edit, delete, or obliterate an instance of a stream An enhanced type of branch with a dedicated view for clients of the stream (see 'stream view') and built-in rules that determine how changes flow across the stream depot (see 'stream hierarchy'). A stream specification defines a stream. In P4V, stream specs are visible in the Streams Graph and the Streams tab. (also known as a stream definition or stream spec).

## Syntax

    p4 [g-opts] stream [-f] [-d] [-P parent] [-t type] [--parentview inherit|noinherit] [name]
    p4 [g-opts] stream [-o [-v]] [-P parent] [-t type] [--parentview inherit|noinherit] [name[@change]]
    p4 stream [-f] --obliterate [-y] name[@change]
    p4 [g-opts] stream [-f] [-d] name
    p4 [g-opts] stream -i [-f]
    p4 [g-opts] stream edit
    p4 [g-opts] stream parentview [-c changelist# -n -o --source-comments] [--inherit | --noinherit]
    p4 [g-opts] stream convertsparse [-q]
    p4 [g-opts] stream resolve [-a<option>] [-n] [-o]
    p4 [g-opts] stream revert

Syntax and naming conventions

## Description

The `p4 stream` command enables you to create a stream spec in a stream depot A depot used with streams and stream clients. A stream depot has structured branching, unlike the free-form branching of other depot types. See also 'classic depot' and 'graph depot'. and maintain P4 Server streams, which are hierarchical branches with policies that control the structure and the flow of change. A stream hierarchy The set of parent-to-child relationships between streams in a stream depot. is based on the stability of the streams, specified by the type you assign to the stream:

Type of stream | Description
--- | ---
`mainline` | Somewhat stable. The parent of all streams in the stream depot.
`development` | Least stable (most subject to change). Flow is controlled.
`sparsedev` | Sparse stream for development with the same flow control as a stream of type `development`. See Sparse streams.
`release` | Highly stable. Flow is controlled.
`sparserel` | Sparse stream for release with the same flow control as a stream of type `release` See Sparse streams.
`task` | Temporary, short-lived stream that only promotes edited files to the repository To maintain performance, a task stream should be deleted or unloaded when its changes are integrated into another stream. A task stream's branched and integrated files are stored in shadow tables that are removed when the task stream is deleted or unloaded. If you integrate from a classic branch or other stream depot to a task stream, the files are not copied up to the parent unless they are edited and submitted first.
`virtual` | Used to copy and merge between parent and child streams without storing local data Not a stream but an alternate view of its parent stream. Because virtual streams do not have files in their depot namespace, it is impossible to import a virtual stream. (2025.2 and later) Consider using an alternative to virtual streams: the LimitView: field of p4 client.

Stream contents are defined by the paths that you map in the stream view A dedicated view shared by all clients of the stream. A stream view is defined by the Paths, Remapped, and Ignored fields of the stream specification.A stream view can be seen with the 'p4 stream -ov' command..

By default, a stream has the same structure as its parent (the stream from which it was branched). However, you can override the structure to ensure that specified files cannot be submitted or integrated to other streams.

By default, `p4 stream` edits the stream associated with your current workspace. It throws an error if you’re not using a stream workspace. To learn more, see Stream views and paths.

A workflow to edit, resolve, and revert a stream is described at Update streams.

### Private editing of streams

If a user edits a stream spec publicly and saves the spec, the changes take effect immediately. In some cases, this can affect other users in unwanted ways. For example, changing any dependency, such as a product module, might break a product build unless corresponding file changes are made as well.

Private editing of streams allows you to:

- Modify a stream spec and stream depot files in isolation from other users of that stream.
- Test the modifications before submitting them, and you can shelve the modifications for another user to test.
- Improve the visibility and tracking of how the stream spec evolves because a single "atomic" changelist can contain both your edits to the stream spec and any associated code changes.

The workflow for private editing of streams corresponds to your normal workflow with the p4 edit, p4 submit, p4 revert, and p4 resolve commands. These commands have been enhanced with the -So option for stream only, no files. In addition,

- p4 revert -Si includes the open stream spec when reverting the specified list of files, and

- p4 submit -Sx exclude stream specs edits.

To learn more, see:

- Stream spec permissions in the p4 protect topic.
- The p4 help streamcmds and `p4 help openablestreamspecs` command-line output.

### Inheritance and streams

The p4 stream specification (2020.2 and later) has the ParentView: field, which can be set with the --parentview parameter to either of the following values:

- inherit, which is the original behavior of streams. The inheritance is implicit, so the inherited Paths, Remapped, and Ignored values are not displayed with the child stream specification.
  - Sparse streams, task streams, and virtual streams must always be inherit.
- noinherit, which means that the Paths, Remapped, and Ignored fields are not affected by the stream's ancestors. For example, the build system for a noinherit release stream continues to build even if the import path of its parent mainline stream has switched to newer libraries that the release stream does not have.
  - Release, development and mainline streams can be inherit or noinherit.
- Because a mainline stream has no parent, the inherit or noinherit settings have no meaning for a mainline stream unless the mainline stream is converted to a different stream type.
- The dm.stream.parentview configurable determines whether a newly-created stream is inherit or noinherit

#### Option: parentview

The p4 stream command also has the parentview option, which can be used to convert an existing mainline, development, or release stream from noinherit to inherit, or from inherit to noinherit. See p4 stream parentview -c 1234 --source-comments --noinherit in Examples

If you convert a child stream to be noinherit, paths that are implicit in an inherit stream become explicit.

- The --source-comments option causes comments to appear in the child stream spec. Such comments begin with ##. For example:
  exclude myExclude/... ## copy from //stream/main@5
  indicate that version 5 of the parent stream spec is the source of this path.
- You can also add manually add comments to a stream spec.

#### Types of streams and StreamDepth of stream depot

For an explanation of the different types of streams and how to use them, see the Streams chapter, including the Update streams topic.

To learn how to create a stream depot and set its StreamDepth, see Working with stream depots in the p4 depot command.

#### Ditto mapping

(2021.2 and later) Support for one-to-many (ditto) mapping of stream specs. See the `import&` `Path:` type under Form fields and the Example of ditto mapping for a stream spec.

#### Prior to the 2019.1 release

Prior to the 2019.1 release, a user could edit a stream spec privately by using the p4 stream edit command. For example,
p4 -c aStreamClient stream edit
Stream //Ace/Main@15973 - edit stream spec default change

However, in such a case, the changelist did not track edits to the stream spec. The p4 stream edit command put the current stream spec of the client into the opened state, isolating any edits made to fields that affect view generation. While the spec was open, those fields were marked with the comment #open to indicate that they were open and isolated to your client. Changes made to these fields affected your client view, but other clients were not affected. The p4 edit -So command had the same effect as p4 stream edit.

### Stream and graph depot - .git suffix and repo path

A stream can import a repo from a depot of type graph. Within the stream, the content of the import is read-only. The examples below show that:

- The .git suffix is required.
- The repo path must include a specific SHA-1 or ref

@sha | Syntax: import path/... //repo/name.git/restricted/view/path/...@sha Example: import d3/... //repo/d3.git/...@c2e37352ac84eb8f90bc2866f715 The imported data is locked at the time of the @sha.
@ref | Syntax: import path/... //repo/name.git/restricted/view/path/...@ref Example: import d3/... //repo/d3.git/...@refs/heads/main or import d3/... //repo/d3.git/...@main A sync updates the data to the current time of the @ref.

P4 Code Review does not support streams specs having imports from 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..

See Working with depots of type graph.

### Stream Components

Stream components is an optional feature that augments client views with the addition of stream component views. The stream spec therefore includes the Components: field.

### Stream specs and triggers

Like files, stream specs can be associated with a trigger. For example, submitting a stream spec in a changelist adds the `%stream%` trigger script variable. See %stream% in the Trigger script variables topic and Change-commit triggers in the P4 Server Administration Documentation.

## Form fields

Field Name | Type | Description
--- | --- | ---
`Stream:` | Writable, mandatory | Specifies the name of the stream (that is, the stream's permanent identifier) and its path in the stream depot, in the form `//`depotname`/`streamname``. All streams in a single stream depot must have the same number of forward slashes in their name. The P4 administrator specifies this number in the `StreamDepth` field of the stream depot spec. If a user tries to create a stream with a different number of forward slashes, the following message appears:
    Error in stream specification. Stream streamname does not reflect depot
    depth-field streamdepth.
Be aware of the Limitations on characters in filenames and entities.
`Update:` | Read-only | The date the stream specification was last modified.
`Access:` | Read-only | The date and time that the stream specification was originally created. For example, `Access: 2023/11/06 17:20:55`
`Owner:` | Writable, mandatory | The P4 Server user or group that owns the stream. The default is the user that created the stream.
`Name:` | Writable | Display name of the stream. Unlike the `Stream` field, this field can be modified. Defaults to the `streamname` portion of the stream path.
`Parent:` | Writable | The parent of this stream. Must be `none` if the stream’s `Type:` is `mainline`, otherwise must be set to an existing stream identifier of the form `//`depotname`/`streamname``.
`Type:` | Writable, mandatory | The stream’s type determines the expected flow of change. Valid stream types are `mainline`, `development`, `sparsedev`, `release`, `sparserel`, `virtual`, and`task`. `mainline` The mainline stream is the parent of all streams in the stream depot. Every stream depot must have at least one mainline stream. `virtual` Virtual streams allow merging and copying between parent and child streams without storing local data. Data is passed through to the destination (a non-virtual stream) after applying restrictions on the scope of files defined in the virtual stream’s view. Because virtual streams do not have files in their depot namespace, it is impossible to import a virtual stream. `release` More stable than the mainline. Release streams copy from the parent and merge to the parent. `sparserel` sparse stream for release with the same flow control as a stream of type `release`. To learn more, see Sparse streams. `development` Less stable than the mainline. Development streams expect to merge from parent streams and copy to the parent. The default is stream type is `development`. `sparsedev` sparse stream for development with the same flow control as a stream of type `development`. See Sparse streams. `task` Task streams are designed to be temporary, short-lived branches for bug fixing or new features that only modify a small subset of the branch data. To keep repository metadata to a minimum, shadow tables track only branched (copied) files. The shadow tables are removed when the task stream is deleted or unloaded. To maintain performance, delete task streams when their contents are integrated into another stream. Workspaces associated with task streams see all branched files, but only modified and promoted files are visible to users with access to the stream’s namespace. For example, if you run p4 describe for a task stream changelist from a workspace that is not associated with the task stream, you might see only a subset of the submitted files.
`Description:` | Writable, optional | Description of the stream.
`Options:` | Writable | Settings that configure stream behavior as follows: `[un]locked` Enable/disable other users' ability to edit or delete the stream. If locked, the stream specification cannot be deleted, and only its owner can modify it. The default is `unlocked`. `[all|owner]submit` Specifies whether all users or only the owner of the stream can submit changes to the stream. The default is `allsubmit`. If the `Owner` of a stream marked `ownersubmit` is a group, all users who are members of that group can submit changes to the stream. `[no]toparent` Specifies whether integrations from the stream to its parent are expected. The default is `toparent`. `[no]fromparent` Specifies whether integrations to the stream from its parent are expected. The default is `fromparent` for mainline and development streams, and `nofromparent` for release streams. `mergedown | mergeany` The default of `mergedown` specifies that the merge flow is restricted to merging down, while `mergeany` permits merging against the expected flow for the stream and issues no warning. A `virtual` stream must have its flow options set to `notoparent` and `nofromparent`. Flow options are ignored for `mainline` streams.
ParentView: | Writable, optional | Defines whether the stream inherits a view from its parent.
inherit | noinherit
--- | ---
If a ParentView is inherit, the Paths, Remapped, and Ignored fields will be affected. The view created from each field is composed of the stream's fields and the set of fields inherited from each of the stream's ancestors. The inheritance is implicit, so the inherited Paths, Remapped, and Ignored values will not be displayed with the current stream specification. | If a ParentView is noinherit, the Paths, Remapped, and Ignored fields are not affected by the stream's ancestors. The child views are exactly what is specified in the Paths, Remapped, and Ignored fields.
The following types of streams always have inherit ParentViews: sparsedev, sparserel, virtual, and task. |
Streams of type development and release can have their ParentView be inherit or noinherit. For a mainline stream, the concept of ParentView is not relevant because a mainline stream has no parent.
When a development, release, or mainline stream is first created, the ParentView field can be set with the --parentview parameter. The parameter can be set with values inherit or noinherit. When creating a development, release, or mainline stream without the --parentview parameter, the configurable dm.stream.parentview determines the default value for the ParentView field. After a stream has been created, the ParentView field cannot be changed by editing the stream specification. Instead, use the command p4 stream parentview to change stream's parentview. For more details, see the output of the p4 help streamcmds command.
`Components:` | Writable, optional | One or more lines that include other streams' views within the current stream. To learn more, see Stream components.
`Paths:` | Writable | Paths define how files are incorporated into the stream structure. Specify paths using the following format: `path_type view_path [depot_path]` where `path_type` is a single keyword, `view_path` is a file path with no leading slashes, and the optional `depot_path` is a file path beginning with `//`. The default path is `share ...` Valid path types are: `share view_path` Specified files can be synced, submitted, and integrated to and from the parent stream. `isolate view_path` Specified files can be synced and submitted, but cannot be integrated to and from the parent stream. `import `view_path` [`depot_path`]` Specified files can be synced, but cannot be submitted or integrated to and from the parent stream. The `view_path` is mapped as in the parent stream’s view, or to an (optional) `depot_path`. The `depot_path` can include a changelist specifier. Client workspaces associated with the stream only see revisions at that change or lower within that depot path. For example, if you specify `//depot/import/...@1000` as the depot path, revisions from changelists greater than 1000 are hidden from most commands. An alternative to using a changelist number is to use an automatic label specification. The changelist limits for a given stream workspace are displayed in a read-only client workspace specification field called `ChangeView`. `import+ `view_path` [`depot_path`]` Functions like a standard `import` path for mapping a path from outside the stream depot to your stream, but unlike a standard import path, allows you to submit changes to the files in an `import+` path. An `import+` path that references a path in a stream depot does not respect the views or flow rules of any other streams that depend on that depot path. Therefore, undesirable interactions are possible. `import& view_path depot_path` for one-to-many (ditto) mapping of streams. This is similar to an `import` path, except that multiple `import&` paths can map a `depot_path` to more than one `view_path`. Files marked this way are readonly and the `depot_path` is required. The `import&` feature requires P4 Server 2021.2 and later and 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.. `exclude view_path` Specified files cannot be synced, submitted or integrated to and from the parent stream. See also the `Ignored:` field, which allows you to exclude files based on the file name rather than the file path. By default, streams inherit their structure from the parent stream (except mainlines, which have no parent). Paths are inherited by child stream views. A child stream’s path can downgrade the inherited view, but not upgrade it. (For example, a child stream can downgrade a `shared` path to an `isolated` path, but if the parent stream defines a path as `isolated`, its child cannot restore full access by specifying the path as `shared`.) The `depot_path` is relevant only when the `path_type` is: `import` `import+` `import&` To manage files of a similar file type in your stream specs, consider using wildcards (... and *) after the final slash (/) in the path definition: Copy
    share ...
        isolate BIN/....CLASS
        isolate BIN/....exe
        import imports/lib/*.a //depot/3rd_party/lib/*.a
        import imports/lib/*.dll //depot/3rd_party/lib/*.dll
        import imports/src/*.h //depot/3rd_party/src/*.h
        exclude doc/....fm
#### Virtual stream import paths In a virtual stream, when you import paths, be specific and provide `import view-path` with a depot-path argument. For example, suppose that you create this set of streams:
    Stream //project1/mainQ mainline none 'mainQ'
    Stream //project1/devQ1 development //project1/mainQ 'devQ1'
    Stream //project1/devQ1-virt virtual //project1/devQ1 'devQ1-virt'
and you use `Paths: share ...` for all except the virtual stream, which has: Paths:
    import foo/...
    share foo/src/libs/lib1/...
Although you might expect that the `foo` path in the virtual stream comes from its parent, `//project1/devQ1`, the client view shows:
    //project1/mainQ/foo/... foo/...
Therefore, it is best to use this more explicit syntax:
    import foo/... //project1/devQ1/foo/...
`Remapped:` | Writable, optional | Reassigns the location of workspace files. To specify the source path and its location in the workspace, use the following syntax: `view_path_1 view_path_2` where `view_path_1` and `view_path_2` are P4 Server view paths (omit leading slashes and leading or embedded wildcards, but terminal wildcards are fine). For example, to ensure that files are synced to the local ProjectX folder, remap as follows: `... projectX/...` Line ordering in the `Remapped` field is significant: if more than one line remaps the same files, the later line takes precedence. Remappings are inherited by child streams and the workspaces associated with them.
`Ignored:` | Writable, optional | A list of file or directory names to be recursively excluded in both: client views for clients of that stream the generated branch spec used in merge and copy operations between the stream and its parent. #### Consider using P4IGNORE Due to their recursive nature, large numbers of Ignored entries can be inefficient. Consider using P4IGNORE as another way to prevent specific filename patterns from being added. A workspace with the following: `//streams/main` Paths: share ... Ignored: /tmp /tmp /...tmp Generates this view: //streams/main/... ... -//streams/.../tmp .../tmp -//streams/.../tmp/... .../tmp/... -//streams/....tmp ....tmp The `...` wildcard immediately following `//stream/` matches any directory in the stream depot, including directories containing files from other streams. #### Mainline stream Lines in the `Ignored` field can appear in any order. Ignored files and directories are inherited by child stream client views. Therefore, it is generally a best practice to set them in the mainline stream.
This entry ... | ignores files ...
--- | ---
`/tmp` | exactly named `tmp`
`/tmp*` | that begin with `tmp`
`tmp` | that end with `tmp`
`.tmp` | with the `.tmp` extension
`tmp*` | with `tmp` anywhere in the file name or file extension
`/tmp/...` | in any directory named `tmp`
See also the Paths: field, which allows you to exclude files based on the file path rather than the file name.

## Options

Option | Description
--- | ---
`-d streamname` | Delete the stream, which creates a changelist, marks the stream specification as deleted, and automatically submits this changelist that records the stream deletion. A stream specification cannot be deleted if it is referenced by any of the following: The stream spec of any child stream. The stream path of any stream client workspace. The `Stream` field in the spec of any client workspace. To learn more, see Stream spec permissions in the p4 protect topic. Deleting a stream spec: Does not remove the files and metadata that are associated with the stream. Only the p4 obliterate command permanently removes files and their associated metadata. For a similar operation that applies to stream specs, see the `--obliterate` option below. Prevents changes from being submitted to the files that were associated with that deleted stream. Does not prevent you from recreating the same stream spec with the same stream name. This would make the files accessible again. To report on deleted streams, use `p4 stream -o deletedStream@change` `p4 streams -a` `p4 streamlog deletedStream` The `p4 change -d -f change` command can delete any changelist that is associated with a stream, even the changelist that was created because the stream was deleted. This command can be run after the deletion of the stream or after the obliteration of the stream.
`-f` | Administrators can use the `-f` option to delete or modify locked streams owned by other users.
`-i` | Read the stream specification from standard input. Even if a stream is locked, the owner can save the stream by using `p4 stream -i` command.
`-o` | Write the stream specification to standard output. By default, it outputs the stream associated with the current workspace. If you pass the `stream@change` option, P4 Server uses the version of the stream as of the specified changelist. Although this option requires the user have at least the list access to the stream path, it ignores any other entry in the protections table, including any minus sign (-) that would otherwise block the operation To report on a delete stream, use `p4 stream -o deletedStream@change` where the changelist number represents the changelist created by `p4 stream -d deletedStream` Even If a stream is locked, the owner can view the stream by using `p4 stream -o` command.
`-o -v` | Verbose option, which includes the automatically-generated client view for this stream.
-c changelist# | If an @changelist specifier is included with the stream name, the (submitted) stream as of that change is displayed rather than the latest (or open) version.
`-P parent` | When creating a new stream specification, specify the stream’s parent. (This option has no effect on an existing stream specification.)
`-t type` | When creating a new stream specification, you must specify the stream’s type: either `mainline`, `development`, sparsedev, `release`, sparserel, `task`, or `virtual`.
parentview | p4 stream parentview can be used with mainline, development, and release streams to set the value of the parentview field to inherit or noinherit. p4 stream parentview does not support setting the value of this field while the stream spec of the workspace client is opened. The command opens the stream spec so you can change value of the ParentView field. You can also change the value of the Paths, Remapped, or Ignored fields. Changes made to the stream spec will not be made public until the change is submitted. Once submitted, the ParentView change is part of the stream spec's integration history.
-c | Associate the stream spec with given changelist# when opening the stream spec for edit.
-n | Previews the changes made.
-o | Display the changed stream spec.
--inherit | Change the ParentView field to inherit. Changes to the Paths, Remapped, and Ignored fields which occurred when converting the stream spec to a noinherit ParentView will remain. Client and branch views for streams with an inherit ParentView property are affected by changes in an ancestor's Paths, Remapped, or Ignored fields.
--noinherit | Change the ParentView field to noinherit. Also converts the Paths, Remapped, and Ignored fields by copy or merging paths from the corresponding fields in the ancestor stream specifications. Client and branch views for streams with a noherit ParentView property are not affected by changes in an ancestor's Paths, Remapped, or Ignored fields.
--source-comments | Add inline source comments to Paths, Remapped, or Ignored lines that were copied or merged from an ancestor stream spec when changing the ParentView field from inherit to noinherit. The comment specifies the source ancestor spec, the change number for head version of the ancestor spec, and whether a given line was copied or merged into the target stream spec.
`convertsparse` | `p4 stream convertsparse` converts a `sparsedev` stream to a `development` stream or a `sparserel` stream to a `release` stream. If it is not already open, the stream specification is opened and any unbranched files from the parent stream are opened in the workspace for branch to the stream. With `-q`, normal output messages are suppressed, so only messages regarding errors or exceptional conditions are displayed. The conversion does not populate the converted stream, but `p4 submit` does. The stream name does not change. To learn more, see Convert a sparse stream to a non-sparse stream.
resolve | p4 stream resolve resolves changes that have been submitted to the stream spec since you opened it. You cannot submit changes to the stream spec until newer changes have been resolved. p4 resolve -So has the same effect as p4 stream resolve (see p4 help edit). When you use `p4 stream resolve`, `-as` performs a "safe" resolve; it skips fields that need merging. `-am` resolves by merging; skips fields with conflicts. `-af` forces a concatenation of text fields with conflicts. `-at` forces acceptance of theirs, overwrites yours. `-ay` forces acceptance of yours, overwrites theirs. `-o -v` previews which fields require resolve. `-n` outputs the base used for the merge.
revert | p4 stream revert reverts any pending changes made to the open spec. The returns your client to the latest submitted version of the stream. p4 revert -So has the same effect as the p4 stream revert command.
`--obliterate` | Permanently deletes the stream from all metadata and removes the stream from pending and committed changelists. This operation can be restricted to a specified changelist by using `p4 stream --obliterate name@change` If the stream is locked, include the `-f` option: `p4 stream -f --obliterate name@change` By default, `--obliterate` displays a preview of the results. To execute the operation, specify the `-y` option. This option requires the `admin` access level in the protections table. This is distinct from deleting files with p4 obliterate. The `p4 change -d -f change` command can delete any changelist that is associated with a stream, even the changelist that was created because the stream was deleted. This command can be run after the deletion of the stream or after the obliteration of the stream.
`-y` | `--obliterate -y` performs the operation instead of displaying a preview of the results.
`g-opts` | See Global options.

## Usage notes

Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required
--- | --- | ---
N/A | N/A | `open` for most options list for the -o option `=openstreamspec` to open a stream spec. See Stream spec permissions. `admin` for `--obliterate`

As the name implies, task streams are intended to be short-lived. When you have finished using a task stream by promoting your changes to its parent, delete the task stream.

## Examples

p4 stream -t mainline //streams/product1 Create a mainline stream in the depot named streams
p4 stream -t development -P main //projectX/bruno-dev Create a development stream for project X by branching the mainline.
p4 stream parentview -n --noinherit Preview the changes that would be made when setting the ParentView field value to noinherit.
p4 stream parentview -c 1234 --source-comments --noinherit Associate the stream spec with changelist 1234, convert the stream to noinherit and get automatic comments about the source of the path, such as ## merge from //str/dev2@25
`p4 stream --obliterate streamname` Preview the results of obliterating the specified stream.
`p4 stream --obliterate -y streamname@change` Obliterate the specified changelist of the specified stream.

### Example of ditto mapping for a stream spec

One possible scenario for ditto mapping a stream spec is that you want to include a platform-independent third-party library (`Lib1`) as `read-only` when you edit a file in a Task stream to provide an enhancement for multiple platforms (`dirWindows` and `dirLinux`).

    Paths:
    share ...
    import& dirWindows/Lib1 //other/main/dirA/fileA
    import& dirLinux/Lib1 //other/main/dirA/fileA

and

    View:
    //sroot/child5/... ...
    &//other/main/dirA/fileA dirWindows/Lib1
    &//other/main/dirA/fileA dirLinux/Lib1

## Related commands

List streams | `p4 streams`
Edit template for streams | p4 streamspec
Report on existing and deleted streams | `p4 streamlog`
Create stream depot | `p4 depot`

Your search for returned results