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

P4 CLI Documentation | 2025.2

# Task streams

Consider using Sparse streams instead of task streams because of the Sparse streams have significant advantages over Task streams..

It is best practice to use sparse streams instead of task streams unless you need to use a feature that sparse streams do not support.

Feature | Task Stream | Sparse Stream
--- | --- | ---
Partial integrations | Partial integrations are supported. By default, the p4 integrate command attempts to integrate (merge) all previously unintegrated changelists between the source and target streams. However, a task stream allows you to integrate a single changelist from a range of unintegrated changelists. This is sometimes called "cherry picking". | Not supported.
The p4 undo command | The `p4 undo` command is supported. | Not supported.
Non-stream depot | Both a stream depot and a non-stream depot (classic depot A repository of P4 files that is not streams-based. Uses the Perforce file revision model, not the graph model. The default depot name is depot. See also 'stream depot' and 'graph depot'.) is supported as the target for integration from a task stream. | Not supported.
Unload | After integration, you should remove the task stream metadata by using `p4 unload`. This is faster than `p4 obliterate` on a development stream. | No need to remove or unload the sparse stream.

If you need to use a feature that Sparse streams do not support, be aware that a task stream is for a short, time-limited task, such as a quick hotfix, correcting a minor bug, or developing a small feature that involves a small number of files.

Delete or unload each task stream as soon as its changes have been integrated. This helps maintain P4 Server performance by keeping the amount of repository metadata to a minimum. See the example at Delete, unload, or convert.

Each task stream requires a unique name, and that name cannot be reused even after the task stream is deleted. Therefore, ask your administrator if your site has a naming convention, such as user-date-taskNumber, where taskNumber represents an identifier or "job" in your issue tracking application.

Task streams, like sparse streams, do not support `p4 unsubmit` and `p4 resubmit`. DVCS and the graph depot A depot of type graph that is used to store Git repos managed by P4 Server. See also Git Connector and classic depot. feature do not support task streams.

## Task streams and depots

A task stream is the only type of stream that can be in a different depot than its parent. To keep a project depot uncluttered by task streams, your P4 Server administrator might choose to establish a depot for task streams. In this case, create your stream in the task streams depot as a child of a parent in the project depot. The separate depot can be 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'. or a classic depot A repository of P4 files that is not streams-based. Uses the Perforce file revision model, not the graph model. The default depot name is depot. See also 'stream depot' and 'graph depot'..

## Task stream promotion, deletion, or unloading

When you submit files in your task stream, archive files are created in the corresponding depot root folder. Make sure that these archive files are incorporated into your backup processes.

When the work has been completed in the task stream, you can delete it. However, because file content relating to this task stream remains in the archive, it is not possible to create a new task stream with the same name.

When you promote the task stream's changes to the task stream's parent stream, a lazy copy is created rather than a full file copy.

The advantage of unloading, rather than deleting, a task stream, is that you can get the task stream back from the unload depot A special depot for infrequently used metadata or to facilitate reloading workspaces that have been moved to a different server.. See Unload infrequently-used metadata in the P4 Server Administration Documentation.

## inherit ParentView

Task streams and virtual streams can only have inherit ParentViews.

## Workflow example

Working within task streams is similar to working in a development stream. The following is an example of a typical workflow.

Suppose that we have a stream depot named Ace and a development stream named //Ace/dev.

### Create and populate

With the workspace associated with the development stream, we create a task stream and then use p4 populate to populate it from the development stream.

    p4 stream -t task -P //Ace/dev //Ace/fixbug1
    p4 populate -r -S //Ace/fixbug1
    2 files branched (change 818).

### Work in task stream

Only a workspace that is associated with a task stream can see the full branch in the task stream. A workspace that is still associated with the development stream does not see any files in the newly-created task stream:

    p4 files //Ace/fixbug1/...
    //Ace/fixbug1/... - no such file(s).

Therefore, we associate the client workspace with the task stream, and then we see the full branch in the task stream:

    p4 client -s -S //Ace/fixbug1
    p4 files //Ace/fixbug1/...
    //Ace/fixbug1/src.cpp#1 - branch change 818 (text)
    //Ace/fixbug1/src.h#1 - branch change 818 (text)

We now start work in the task stream and submit content changes:

    p4 add //Ace/fixbug1/foo
    //Ace/fixbug1/foo#1 - opened for add
    p4 submit -d "Add new file to task stream"
    p4 sync //Ace/fixbug1/src.cpp
    p4 edit //Ace/fixbug1/src.cpp
    //Ace/fixbug1/src.cpp#1 - opened for edit
    p4 submit -d 'Update to src.cpp in task stream'

We see any changes:

    p4 files //Ace/fixbug1/...
    //Ace/fixbug1/foo#1 - add change 819 (text)
    //Ace/fixbug1/src.cpp#2 - edit change 820 (text)
    //Ace/fixbug1/src.h#1 - branch change 818 (text)

### Merge down, copy up

Content changes in a task stream are promoted when the file action is not a branch or copy. We now associate the workspace with the development stream, and we see that the changes have been promoted from the task stream:

    p4 client -s -S //Ace/dev
    p4 files //Ace/fixbug1/...
    //Ace/fixbug1/foo#1 - add change 819 (text)
    //Ace/fixbug1/src.cpp#2 - edit change 820 (text)

Before we copy changes from the task stream to the development stream, we merge down any changes from the development stream:

    p4 client -s -S //Ace/fixbug1
    p4 sync -q
    p4 merge //Ace/dev/... //Ace/fixbug1/...
    //Ace/fixbug1/src.cpp#2 - integrate from //Ace/dev/src.cpp#2
    p4 resolve -am
    p4 submit -d 'Merging from dev branch'

Now we copy up changes from the task stream:

    p4 client -s -S //Ace/dev
    p4 sync -q
    p4 copy //Ace/fixbug1/... //Ace/dev/...
    //Ace/dev/foo#1 - branch/sync from //Ace/fixbug1/foo#1
    p4 submit -d 'Copy changes from task stream to dev'

## Delete, unload, or convert

Finally, we free up space in P4 Server database tables. To do so, we can delete or unload the task stream.

Delete | Unload
--- | ---
We cannot work on a task stream after we’ve deleted it, and it cannot be recovered.
    p4 stream -d //Ace/fixbug1
    Stream //Ace/fixbug1 deleted.
| Alternatively, we can unload the task stream. Unloading gives us the option of recovering the task stream to work with it again. We unload a task stream using the `p4 unload` commmand. See `p4 unload`.
    p4 unload -s //Ace/fixbug1
    Stream //Ace/fixbug1 unloaded.
We can now archive this task stream to the archive depot:
    p4 archive -D archive-depot //Ace/fixbug1
At any time, an unloaded task stream can be reloaded. See the `p4 reload` command.
    p4 reload -s //Ace/fixbug1
    Stream //Ace/fixbug1 reloaded.

### Convert a task stream to a development stream

If you edit more than half the files in your task stream, that stream will no longer reduces repository metadata when it is deleted or unloaded. Consider converting the task stream to a development stream.

If you convert a task stream to a development stream, the change is permanent because you cannot convert a non-task stream to a task stream.

1. Issue the command to open the task stream in your default editor. For example,

   `p4 stream //project1/bug123`

2. In the editor, change the value of the `Type` field from `task` to `development`, save the file, and close your editor.

3. Submit your change with the `p4 submit` command.

Your search for returned results