Task streams
A task stream is well suited for a limited task, such as fixing a bug or developing a small feature. A task stream is a lightweight branch that affects a small number of files relative to the total number of files in the branch. A task stream is often temporary, and deleted or unloaded when its changes have been integrated.
Task streams can help Helix Core Server performance by keeping the amount of repository metadata to a minimum.
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.
DVCS does not support task streams.
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. 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 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.
An alternative to deleting or unloading a task stream is to convert it into a regular stream, such as a development stream. If you edit more than half the files in your task stream, that stream no longer reduces repository metadata. In this case, consider converting your task stream.
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.
