Notes on Promote-by-Issue : Cross-Promoting Issues to a Non-Parent Stream — Patch Required

Cross-Promoting Issues to a Non-Parent Stream — Patch Required
In this scenario, your intention is the same as in the preceding one — to cross-promote the versions in one or more issues from one dynamic stream to another. Before proceeding, please see definition of the following terms in the AccuRev Glossary chapter of the AccuRev Concepts Manual: direct, indirect, incomplete, cyclical, and coalesce.
You start the same way, with a drag-and-drop operation from stream brs34_able to stream brs34_baker:
As before the elements in the issue(s)’ change packages are loaded into the Change Palette. But in this scenario, one or more of the elements is listed with (patch) status:
This occurs when the element’s change-package entry does not contain the complete set of changes to the element that (1) are in the source stream and (2) have not yet been promoted to the destination stream:
Changing the Way You Use the Change Palette
In the situation described in the preceding section, you might be accustomed to dealing with the (patch)-status element separately from the other elements. But do not proceed in this manner! Instead, close the Change Palette tab without propagating any of the changes to the destination stream.
Note: What happens if you proceed to use the Change Palette in the traditional way, processing the (patch)-status element separately? See If You Process Some Elements at the Stream Level, not the Workspace Level on page 63 for an explanation.
Now, populate another instance of the Change Palette with a drag-and-drop operation of the same issue(s) from the source stream to a workspace below the destination stream:
The new Change Palette display is similar to that of the previous instance. Process the elements as indicated below:
What about (overlap) status? If you have made changes to one or more of these elements in this workspace, some of the elements will have (overlap) status. For such elements, you can use Merge instead of Send to Workspace.
If an element has both (patch) and (overlap) status, use the Patch command, not the Merge command. AccuRev warns you if you attempt to merge. In this case, click Cancel and invoke the Patch command instead.
After you have processed all the elements in the issue(s), each Patch’ed element is listed at the bottom of the Change Palette:
Although you might be accustomed to promoting Patch’ed and Merge’d elements from the Change Palette, do not proceed in this manner. Instead, close the Change Palette tab without invoking Promote.
At this point, the selected issue(s) have been propagated to the workspace below the destination stream. Each issue is listed in the workspace’s development activity subwindow with a special variant of the issue icon:
Promotion / Creating a Tracking Issue
When your work on the issue is finished, you must use promote-by-issue to send your changes to the workspace’s backing stream (the original destination stream of the cross-promote). Don’t use promote-by-element or promote-by-transaction, which would defeat AccuRev’s ability to track changes related to the selected issue(s). When you invoke the Promote command, AccuRev prompts you to specify an additional issue, called a tracking issue. This is the mechanism that AccuRev uses to record the changes made in this workspace to the original issue(s)’ elements.
A single tracking issue can keep track of the additional changes for any number of original issues. Thus, it makes sense to select New Issue the first time you need to specify a tracking issue, and select Use Existing on subsequent uses of promote-by-issue in the same workspace. You might also need to select Use Existing if you’re not allowed to create new issues — for example, if you’ve integrated a third-party issue-tracking system with AccuWork.
Either way, an AccuWork edit form appears, in which fill in the fields of the new or existing tracking issue. As usual, click the edit form’s Save button when you are finished filling in the fields.
AccuRev automatically proceeds with your original command, Promote: its prompts you for a comment, then sends the versions from the workspace to the original destination stream. The cross-promotion of the original issue(s) is now complete — after just a bit of a detour!
Working with the Tracking Issue
The Stream Browser shows that the original issue (in our example, #8) has been promoted from the source stream (brs34_able) to the destination stream (brs34_baker). The tracking issue (#11) records the additional changes to issue #8’s elements that have been propagated to the destination stream.
AccuRev Version 4.6 introduced change package dependency tracking, whose goal is to ensure that a Promote operation sends a self-contained, consistent set of changes to the destination stream. A tracking issue and the corresponding original issue(s) are connected by a change package dependency: the tracking issue depends on the original issue(s).
The best way to monitor such connections is with a Relationship field whose type is Track. For example, when issue #8 is viewed in an edit form, its connection to issue #11 might be displayed like this:
As with all change package dependencies, AccuRev warns you if you attempt to promote a tracking issue without its dependencies, the original issue(s). In this situation, don’t click Proceed! It’s important always to promote both the original issue(s) and the tracking issue at the same time. So the correct procedure is to Cancel, select both the original and tracking issues, then invoke Promote again.
As you propagate issues up (or across) the stream hierarchy, you must continue to obey this same rule:
Always promote original issues and the corresponding tracking issues at the same time.
If you attempt to Promote an original issue alone, without including its tracking issue, AccuRev prompts you to promote the tracking issue as well.
If You Process Some Elements at the Stream Level, not the Workspace Level
Section Changing the Way You Use the Change Palette on page 58 describes a new way to use the Change Palette, but does not describe what occurs if you continue to use the old way. This section provides the details.
Suppose you have populated the Change Palette with a drag-and-drop operation, as illustrated below:
If you proceed to Promote elements add_cr.pl and tools.readme to the destination stream and Patch element commands.c to a workspace below the destination stream, you create the following situation:
(This is a composite picture — the Stream Browser displays the development activity for only one stream at a time.) Issue #6 has been “taken apart” by the Promote/Patch sequence in the Change Palette. The issue is not completely “in” stream brs71_baker, nor is it completely “in” workspace brs71_baker_john. Switching to the Stream Browser’s file mode confirms that issue #6 has been “taken apart”.
(Again, this is a composite picture.) Two of issue #6’s three elements have been sent to one destination, and the third element has been sent to another destination.
Fixing Your Mistake
If you get yourself into this situation, what is the remedy? There are two options. Revert to Backed, or Promote the missing file.
Revert to Backed: First, use Revert to Backed to “undo” all the Promote(s). Then, switch the Stream Browser back to issue mode, and proceed as described in section Changing the Way You Use the Change Palette on page 58. That is, drag-and-drop the original issue(s) to the workspace below the original destination stream. (In this example, drag-and-drop issue #6 to workspace brs71_able_john.)
Promote the missing file: From the workspace, select the file and Promote against an issue which will track the changes made for this issue.
You have now “reunited” the changes to all of the issue(s)’ elements at a single destination. The Stream Browser confirms this.





 

AccuRev, Inc.
Phone: 781-861-8700
Fax: 781-861-8704
support@accurev.com