P4V Documentation | 2025.1

# About streams

Helix Core Server streams provide an approach to managing bodies of related files, such as codelines. Streams associate these files with rules that define how users can work with those files, including how users can move changes between them. Streams are defined hierarchically using the mainline model, and Helix Core Server generates the views for workspaces that are associated with a stream A branch with built-in rules that determine which changes to propagate to files in a stream depot, and in what order. A stream specification defines a stream. A user creates a stream spec by using the 'p4 stream' command or in P4V with File > New Stream. In P4V, stream specs are visible in the Streams Graph and the Streams tab.. Among the advantages of this approach are:

- Change is propagated in a controlled way through the hierarchy that you define.
- You can compose the contents of a stream by defining its view, thereby providing all users who work in the stream with a consistent view of its contents.
- Some best practices, such as merge down from parent before allowing copy up to parent, are enforced automatically.

If you are new to working with the Perforce version control system, you have not yet established a robust codeline policy and associated workflow, or you do not have the staff to customize Helix Core Server by writing trigger code, using streams is a good option for you. Streams come with reduced administration duties for codeline policy and workspace management, and the Stream Graph provides a graphical representation of the relationship between parent and child streams and whether a merge is required.

This chapter focuses on working with streams in P4V. For additional stream-related information, see:

- the Streams chapter in the Helix Core Command-Line (P4) Documentation
- the p4 stream command in the Helix Core Command-Line (P4) Reference

- the description of the dm.stream.parentview and dm.integ.streamspec configurables in the Helix Core Command-Line (P4) Reference

## Stream depots

Streams are stored in a stream depot, which is displayed in P4V like this: . You cannot add a stream to a "classic" Helix Core Server depot. You can add streams depots through P4Admin or the P4 command-line client.

P4V displays the stream badge both for the stream depot and the folder that contains the files associated with the stream. For example, the Depots tab shows `//flow/D1` is a stream name within the stream depot named `flow`.

However, to work with the stream (or stream spec), see Stream Graph and use the Stream tab (see View and add tabs).

For more information, see Set up streams.

## Stream types

Type | Description
--- | ---
release | A stream that is more stable than its parent. Expects merging down from more stable child streams. Does not expect copying up from its parent stream. Useful for ongoing stabilization, bug fixing, and release maintenance.
mainline | A stream with no parent. Expects merging down from more stable child streams. Expects copying up from less stable child streams. The `mainline` stream is typically the parent of the `release`, `sparserel`, `development`, and `sparsedev` streams.
development | A `development` stream is less stable than its parent. Expects merging down from its parent stream. Expects copying up from its less stable child streams. Does not expect to have more stable child streams. Useful for long-term projects and developing major new features.
sparsedev sparserel | Sparse streams are lightweight: no need to wait a long time for the initial populate command, and no need to delete or unload to maintain performance. In terms of flow rules : `sparsedev` is similar to `development` `sparserel` is similar to `release` You can convert a `sparsedev` stream to `development`, and a `sparserel` stream to `release`. To learn more, see Sparse streams.
task | Consider using sparse streams instead of task streams because sparse streams have significant advantages over task streams. Use sparse streams instead of `task` streams unless you need a feature that sparse streams do not support. Task streams should be temporary. After you integrate the changes in task streams, you should Delete and unload task streams Otherwise database metadata accumulation can affect performance. To convert an existing `task` stream to a `development` stream, see Convert a task stream to a development stream.
virtual | Restricts the workspace view of a real stream. Virtual streams act as a filter. They are useful when you want to: Submit changes directly to a stream, but do not want to sync all of the files in the stream view to your workspace. Develop against the same stream but switch imported libraries, such as when you develop across multiple platforms See Work with virtual streams.

## The mainline model

The mainline model of software configuration management defines a stream hierarchy The set of parent-to-child relationships between streams in a stream depot. based on the stability of the contents of the stream, from softest (unstable or experimental) to firmest (high quality, releasable).

The `mainline` codeline is fairly stable (for example, code must build). `development` and `sparsedev` codelines are less stable. `release` and `sparserel` codelines are the most stable. |

### Propagate change between streams

The principle of change propagation is merge down, copy up. The goal is to keep less stable streams up to date with their more stable parent or child, so that when change is propagated from a less stable stream to a more stable one, no work is overwritten. This approach keeps the resolve operation as simple as possible. The merge/copy and resolve features allow you to propagate change between streams.

If you want to merge or copy between peer streams (for example, to merge another developer's changes to your development stream), you must first reparent your stream. To reparent a stream, edit the stream specification and change the Parent field. This approach is a key benefit of streams: the ability to configure the flow of change.

For more information, see Merge down and copy up between streams.

## Stream specification and inheritance

A stream specification, also called the stream spec, has a set of field names.

The Advanced tab of the Stream: Edit dialog box shows the stream view. The stream view consists of the `Paths`, `Remapped`, and `Ignored` fields. The stream view controls the files and paths that compose a stream and defines how those files are propagated. |

Prior to P4V 2020.3, a stream always inherited its view from its parent stream.

Starting with P4V 2020.3, this inheritance is associated with the stream spec's ParentView field having the value of `inherit`.

This assumes that P4V is running against the 2020.2 version or later of Helix Server.

You might want to set up release streams to not inherit from the parent stream so changes to the parent stream do not affect the release streams. To provide this kind of flexibility, release, development, and mainline streams can have the ParentView field set to `noinherit` when the stream is created or at any time thereafter.

When the stream is created, the `Parent view` field of the Stream: New dialog box is affected by the value of the dm.stream.parentview configurable.

`0` (default) | all streams created with Parent view: `inherit`
`1` | mainline, development, and release streams created with Parent view: `noinherit` task and virtual streams created with Parent view: `inherit`
`2` | release streams created with Parent view: `noinherit` other stream types created with Parent view: `inherit`

For any time after the stream is created, see Convert the Parent View of a stream.

A mainline stream has no parent, so `inherit` versus `noinherit` is relevant only if the mainline stream is converted to another type of stream.

In some cases, a child stream that does not inherit its view from its parent might benefit from changes in the parent's view. Such a child stream can integrate the changes. See Stream spec integration.

## Stream views and branching

Stream views:

- define the files that you can work on in your workspace and what you can do with them
- restrict the files that a child stream inherits from its parent, if the stream is configured to inherit from its parent. For example, let's say you have a mainline stream that includes the following directories of files:

>     //Acme/Main
>      --apps
>      --api
>      --resources
>      --docs

You want to branch to a development stream. You only need to work in the `apps` folder, but you need resources from the api and resources folders. You can create a development stream as a child of `Main` that includes the files in the `apps` folder, excludes the files in the `docs` folder, and imports the contents of the `api` and `resources` folders so you can use them but cannot edit and submit any changes to the depot.

You assign a stream view to the child stream that enacts these rules. Helix Core Server generates the workspaces from the stream view. The stream view enforces the submit and integration rules. Any children branched from this new stream inherit those rules, if those streams inherit from their parent.

You can assign a more restrictive stream view to subsequent children, but you cannot assign a less restrictive one. Child streams cannot branch more than their parent streams are willing to share.

For more information, see Stream view configuration.

## Stream hierarchy in the Stream Graph

The stream graph displays the parent-child relationships that control the propagation of change between codelines. All streams are children of the mainline. All children can be parents of yet more children. This enables specific development and release codelines while ensuring that changes are propagated properly between codelines. The stream graph represents those directions of change propagation using arrow connectors.

The Stream graph displays soft streams below the mainline and firm streams above it. A typical software development structure consists of a stable mainline (`main1`), with less stable or "softer" development streams below it (`dev1`, `dev2`, `dev11`, `dev22`), and the most stable or "firmer" release streams, such as `rel1`, above:

The mainline stream is the parent of `rel1`, `dev1`, and `dev2`.

- The blue band on `rel1`, `dev2`, and `dev11` means those streams are `noinherit` and therefore do not inherit their view from their respective parent streams.
- The grey band on `dev1` and `dev22` mean those streams do inherit their view from their respective parent streams.
- The mainline stream has no parent, so its band color has no meaning unless the mainline stream is converted to a different stream type.

Suppose that in preparation for a future release, the mainline gets a new set of library files. A `noinherit` release stream can continue to build as usual, independent of changes to the parent stream.

For more information, see Stream Graph.

## Terminology differences between command line client and P4V

P4V Term | Command Line Term | Description
--- | --- | ---
Stream Root | Stream | The top level under the depot where files in the stream are stored.
Stream | Name | A descriptive name that you assign and which is displayed to label the streams in the Stream Graph.

Your search for returned results