Streams and Issues
The Stream Browser and File Browser enable you to see what individual versions are present -- and perhaps active -- in a stream. AccuRev also makes it easy to answer questions like these:
"Are all the changes required to fix bug #4517 in this stream?"
"Are any of the versions involved in the #4517 fix still active in this stream? (Or have all the changes already been promoted to a higher-level stream?)"
"What new features are still under active development in this stream?"
"The QA Group says they don't have all the Color Mixer changes for the upcoming release. Is that true?"
The key is to go beyond thinking of individual versions to considering collections of versions, called change packages A set of entries, each in the form of a basis-version/head-version pair, recorded on the Changes tab of an issue record. The change package records the changes to one or more elements, made to implement the feature or bugfix described in that issue record. Each entry in the change package describes changes to one element: the changes between the basis version and the head version. See patch.. With AccuRev, change packages are implemented by AccuWork issue records. An issue record records the details of a bug or feature: its description, how important it is, who originated it, who's working on it, and so on. In the AccuRev Enterprise version of AccuWork, an issue record can also keep track of the changes that have been made to elements, in order to implement that particular bugfix or new feature.
For example, issue record #9 might contain a bug report, "Circles are not round". The bugfix involves changes to three elements:
When viewing the issue record through its edit form, go to the Changes tab to view the change package. In this example, the change package contains three entries:
The set of changes that were made between version 5/10 and version 5/24 of element chap03.doc
The set of changes that were made between version 5/11 and version 5/17 of element commands.c
The set of changes that were made between version 5/7 and version 4/5 of element end.sh
See Patches and Change Packages for the precise definition of "between".
As the versions in a change package are promoted up the stream hierarchy, the change package itself implicitly moves up the hierarchy, also. Roughly speaking, a change package has risen to a certain level if all its entries have risen to that level. More precisely:
The change package entry for an element is said to be "in" a particular stream if the element's version in the stream is -- or is a descendent of -- the head version (Version column).
Notes (click to view):
Why the "or is a descendent of" clause?
AccuRev assumes that changes made to an element remain in that element as subsequent versions are created. Suppose a change package entry consists of versions 13/4, 13/5, and 13/6 of some element. Another user then brings version 13/6 into her workspace with an Update, and creates descendent version 49/2. It's fair to say that the change package entry is "in" her workspace, and in any stream to which version 49/2 is promoted.
Why mention the head version, but not the basis version?
The basis version of a change package entry is always an ancestor of the head version. AccuRev assumes that changes that were present in the ancestor version remain in the later version.
A change package is said to be "completely in" a particular stream if all of its entries are "in".
A change package is said to be "partially in" a particular stream if some -- but not all -- of its entries are "in".
A change package is said to be "active" in a particular stream if at least one of its head versions is in the stream’s default group.