p4 stream

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.

Error in stream specification. Stream streamname does not reflect depot
depth-field streamdepth.

Be aware of the Limitations on characters in filenames and entities.

The date the stream specification was last modified.

The date and time that the stream specification was last accessed by any Helix Core Server command.

The Helix Core Server user or group that owns the stream. The default is the user that created the stream.

Display name of the stream. Unlike the Stream field, this field can be modified. Defaults to the streamname portion of the stream path.

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.

The stream’s type determines the expected flow of change. Valid stream types are mainline, development, sparsedev, release, sparserel, virtual, andtask.

• 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. See Sparse streams in the Helix Core Command-Line (P4) Guide.

• 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 in the Helix Core Command-Line (P4) Guide.

• 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 of the stream.

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.

Defines whether the stream inherits a view from its 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.

One or more lines that include other streams' views within the current stream. For details, see Stream Components in the Helix Core Command-Line (P4) Guide.

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 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.

  Warning

  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 Helix Core 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 Helix Core 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.

Note

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:

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

Stream //project1/mainQ mainline none 'mainQ'
Stream //project1/devQ1 development //project1/mainQ 'devQ1'
Stream //project1/devQ1-virt virtual //project1/devQ1 'devQ1-virt'

import foo/...
share foo/src/libs/lib1/...

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 Core 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.

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

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 streamlogdeletedStream

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.

Administrators can use the -f option to delete or modify locked streams owned by other users.

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.

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 Core Server uses the version of the stream as of the specified changelist.

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.

Verbose option, which includes the automatically-generated client view for this stream.

When creating a new stream specification, specify the stream’s parent. (This option has no effect on an existing stream specification.)

When creating a new stream specification, you must specify the stream’s type: either mainline, development, release, task, or virtual.

p4 stream parentview can be used with mainline, development, and release streams to set the value of the parentview field to inherit or noinherit.

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.

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 in the Helix Core Command-Line (P4) Guide.

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).

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.

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

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.

p4 streams