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 Helix Core files that is not streams-based. Uses the Perforce file revision model, not the graph model. The default depot name is depot. See also default depot, 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.

Task streams, like sparse streams, do not support p4 unsubmit and p4 resubmit.

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.

Restriction: DVCS and the graph depot A depot of type graph that is used to store Git repos managed by Helix Core 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 Helix 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 Helix Core files that is not streams-based. Uses the Perforce file revision model, not the graph model. The default depot name is depot. See also default depot, 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 Helix Core Server Administrator Guide.

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 Helix Server database tables. To do so, we can either delete or unload the task stream. 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 in Helix Core Command-Line (P4) Reference.

$ p4 unload -s //Ace/fixbug1
Stream //Ace/fixbug1 unloaded.

At any time, an unloaded task stream can be reloaded. See p4 reload in Helix Core Command-Line (P4) Reference.

$ p4 reload -s //Ace/fixbug1
Stream //Ace/fixbug1 reloaded.

An alternative to deleting or unloading a task stream is to convert it into 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. In this case, consider converting your task stream.

Convert a task stream to a development 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.