Task streams

Task streams are lightweight short-lived streams used for bug fixing or new features that only modify a small subset of the stream data. Since branched (copied) files are tracked in a set of shadow tables that are later removed, repository metadata is kept to a minimum when using this type of stream and server performance is optimized.

They are branches that work just like development streams, but task streams remain semi-private until branched back to the parent stream. Designed as lightweight branches, they are most effective when anticipated work in the branch will only affect a small number of files relative to the number of files in the branch.

Task streams are intended to be deleted or unloaded after use. Because you cannot re-use task stream names even after the stream has been deleted, most sites adopt a naming convention that is likely to be unique for each task, such as user-date-jobnumber.

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 an existing stream depot named Ace and a defined development stream named //Ace/dev.

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

Only a workspace that is associated with a task stream can see the full branch in the task stream. The stream appears as a sparse branch to other workspaces, which see only those files and revisions that you changed within the task stream. Most other metadata for the task stream remains private. Because the workspace is still associated with the development stream, we don't see any files in the newly created task stream:

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

Therefore, we associate the 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)

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'

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.

Task streams and depots

A unique feature of task streams is that it can be in a different depot than its parent. However, generally speaking, the best practice is to use the same depot.

To keep a project depot uncluttered by task streams, your Helix Server administrator or project lead 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.

Task stream reuse

When you submit files in your task stream, archives 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.

inherit ParentView

Task streams and virtual streams can only have inherit ParentViews.