Helix Core P4 Command Reference (2019.2)

p4 stream

Create or edit an instance of a stream (also known as a stream definition).

Syntax

p4 [g-opts] stream [-P parent] -t typename name
p4 [g-opts] stream [-f -d] [-o [-v]] [-P parent] -t typename [name[@change]]
p4 [g-opts] stream -i [-f] name
p4 [g-opts] stream edit
p4 [g-opts] stream resolve [-a flag] [-n] [-o]
p4 [g-opts] stream revert

Description

The p4 stream command enables you to maintain Helix server streams, which are hierarchical branches with policies that control the structure and the flow of change. Stream hierarchies are based on the stability of the streams, specified by the type you assign to the stream:

mainline	somewhat stable the parent of all streams in the stream depot
development	least stable (most subject to change) flow is controlled
release	highly stable flow is controlled
task	lightweight short-lived stream that only promotes edited files to the repository branched and integrated files are stored in shadow tables that are removed when the task stream is deleted or unloaded
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

Stream contents are defined by the paths that you map. By default, a stream has the same structure as its parent (the stream from which it was branched). However, you can override the structure. For example, your override might 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. For more information, see the "Streams" chapter of the Helix Core Server User Guide.

For details on the recommended workflow to edit, resolve, and revert a stream, see "Update Streams" in Helix Core Server User Guide.

Note

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.

For a detailed discussion of streams, see the Streams chapter of the Helix Core Server User Guide.

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 product component, might break a product build.

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 your edits to the stream spec and any associated code changes

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

However, if you use p4 stream edit the changelist does not track edits to the stream spec.
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, -Si, or -Sx options to include or exclude stream specs edits.

See also the p4 help streamcmds command-line output.

Tip

To learn how to create a stream depot and set its StreamDepth, see Working with stream depots in the p4 depot command.
For a complete explanation of the different types of streams and how to use them, see the Streams chapter in the Helix Core Server User Guide, including the "Update streams" topic.

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/*.js@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@refs/heads/master

A sync updates the data to the current time of the @ref.

See Working with depots of type graph.

Form Fields

Field Name	Type	Description
`Stream:`	Writable, mandatory	Specifies the stream’s name (permanent identifier) and its path in the stream depot, in the form `//depotname/streamname`. 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 last accessed by any Helix server command.
`Owner:`	Writable, mandatory	The Helix server user or group who owns the stream. The default is the user who 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`, `release`, `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. `development` Less stable than the mainline. Development streams expect to merge from parent streams and copy to the parent. Note The default is stream type is `development`. `task` Task streams are lightweight, short-lived branches that are useful 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. Note 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 Tip You cannot submit files to an import+ path in a task stream. See the explanation of the path type, import+ view_path [depot_path].
`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. `mergeany \| mergedown` Specifies whether the merge flow is restricted or whether merge is permitted from any other stream. For example, the `mergeany` option would allow a merge from a child to a parent with no warnings. A `virtual` stream must have its flow options set to `notoparent` and `nofromparent`. Flow options are ignored for `mainline` streams.
`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. Note Instead of a changelist number, you can 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, enable you to map a path from outside the stream depot to your stream, but unlike a standard import path, you can submit changes to the files in an `import+` path. `exclude view_path` Specified files cannot be synced, submitted or integrated to and from the parent stream. 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`.) Note that the `depot_path` is relevant only when the `path_type` is `import` or `import+`. Tip 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 `project1` path in the virtual stream comes from its parent, `//project1/devQ1`, the client view shows: `//project1/mainQ/foo/... foo/...` Therefore, we recommend that you use this more explicit syntax: `import foo/... //project1/devQ1/foo/...` Note To manage files of similar file-type in your stream specs, consider using wildcards (... and ) explicitly following the final slash in the path definition: `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`
`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 Helix 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 ignored in client views. For example: /tmp # ignores files named "tmp" /tmp/... # ignores directories named "tmp" .tmp # ignores file names ending in .tmp Lines in the `Ignored:` field can appear in any order. Ignored files and directories are inherited by child stream client views.

Options

`-d streamname`	Delete the stream specification. A stream specification cannot be deleted if it is referenced by child streams or stream client workspaces. Deleting a stream does not remove its files. However, changes can no longer be submitted to 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.
`-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` argument, Helix server uses the version of the stream as of the specified changelist. Warning Limitation: 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.
`-o -v`	Verbose option; includes the automatically-generated client view for this stream.
`-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`, `release`, `task`, or `virtual`.
`-as`	For `p4 stream resolve`, performs a "safe" resolve; it skips fields that need merging.
`-am`	For `p4 stream resolve`, resolves by merging; skips fields with conflicts.
`-af`	For `p4 stream resolve`, forces a concatenation of text fields with conflicts.
`-at`	For `p4 stream resolve`, forces acceptance of theirs, overwrites yours.
`-ay`	For `p4 stream resolve`, forces acceptance of yours, overwrites theirs.
`-o -v`	For `p4 stream resolve`, previews which fields require resolve.
`-n`	For `p4 stream resolve`, outputs the base used for the merge.
`g-opts`	See Global options.

Usage Notes

Can File Arguments Use Revision Specifier? Can File Arguments Use Revision Range? Minimal Access Level Required

Can File Arguments Use Revision Specifier?	Can File Arguments Use Revision Range?	Minimal Access Level Required
N/A	N/A	`open` or list to use the -o option

N/A

open

or list to use the -o option

As the name implies, task streams are intended to be short-lived; after 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.

Related Commands

List streams	`p4 streams`
Edit template for streams	p4 streamspec
Create stream depot	`p4 depot`

Your search for returned result(s).