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.

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 Helix Core 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 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 Core 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 the 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 Core Server database tables. To do so, we can delete or unload the task stream.

p4 stream -d //Ace/fixbug1
Stream //Ace/fixbug1 deleted.

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

p4 archive -D archive-depot //Ace/fixbug1

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.

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.