This scenario describes how to:
Shelve local changes into a topic stream.
Publish a pull request and start a review.
Add comments to a pull request and send it for rework.
Resolve conflicts between a topic stream and its parent.
Approve and merge a pull request.
Sam is assigned the request QLARIUS_ENH_7 to add a new feature to the Qlarius application. He starts development in the work area C:\Work_Main, which is associated with the mainline stream, QLARIUS_MAIN.
Sam launches the web client and opens his default stream QLARIUS_MAIN with the work area set to C:\Work_Main. This work area contains all his local changes. Sam starts to make changes to the code.
Sam decides that his changes are not ready to deliver to the mainline stream. So he decides to branch them from the local work area into a topic stream using the shelving feature.
Before shelving, Sam uses the Update operation to fetch the latest repository content from the mainline into the work area. This ensures that the new topic stream will contain the most recent sources.
Sam selects the Folders and Items view and on the toolbar clicks Shelve.
In the Shelve wizard, Sam specifies a name for topic stream that is the same as the request related to the work, QLARIUS_ENH7. This makes it easier to identify the purpose of the stream. He also specifies a unique branch name and a description.
Sam wants to continue working on this enhancement in the current work area after shelving, so he selects the Rehome option. The work area will be associated the new topic stream after shelving.
In the Shelve wizard, Sam verifies that all parameters are set as expected, validates the file changes to be shelved, and specifies a comment for the uploaded changes.
Note: Shelving, or delivering to a topic stream, does not require a request. Request QLARIUS_ENH_7 will be used when merging changes into the mainline.
After the local changes are shelved, Sam switches the web client to the new topic stream, QLARIUS_ENH7. The work area, C:\Work_Main, is rehomed to the new topic stream that he just created.
Note: QLARIUS_MAIN has been configured to automatically create pull requests from topic streams.
Sam completes the enhancements to the topic stream and delivers the changes to the repository. To start the peer review process he does the following in the web client:
In the My Current Stream tab selects Pull Request on the side panel. The pull request opens in the main window.
In the Requests section, relates QLARIUS_ENH_7 to the pull request. This is the request that will be used for the merge.
Adds Arlene as a reviewer.
Clicks Publish. The pull request is assigned to Arlene for code review.
Arlene receives an email notification that there is a new pull request in her inbox ready for review. She clicks the link in the notification, which opens the pull request in Pulse. The request contains a list of all the changes that Sam made in the topic stream QLARIUS_ENH7. Arlene reviews the code, adds comments to the pull request suggesting changes, and votes Request Changes to send it for rework.
Sam receives a notification that the pull request has been sent for rework. He implements the changes proposed by Arlene. He also notices a warning in the pull request that it cannot be automatically merged because of conflicting changes in the mainline stream introduced by a different team member. To resolve the conflicts Sam:
Merges the mainline stream QLARIUS_MAIN into the work area, C:\Work_Main, and resolves all the conflicts.
Delivers the changes in the topic stream QLARIUS_ENH_7 to the repository, including the changes requested by Arlene.
Publishes the pull request again for Arlene to review.
Arlene is satisfied with the latest changes and votes to approve the pull request.
Sam opens the pull request and clicks Merge Pull Request, which automatically merges all the topic stream changes into the mainline.
Sam can now rehome the work area C:\QLARIUS and continue development on mainline changes, or branch another topic stream and work on a different task.