version kestrel_dvt_jjp/13 of element /./src/brass.c
version kestrel_dvt_jjp/14 of element /./src/brass.h
version kestrel_dvt_jjp/16 of element /./src/commands.cThe basic idea is that this set (or “package”) of versions contains all the changes required to implement a certain development project. But we need to refine this idea. Consider that version 14 of brass.h probably contains more than just the changes for that development project. For example:So we need a way to express the idea that only the “recent changes” to brass.h, those in versions 10-14, are to be included in the change package. AccuRev accomplishes this by defining each change package entry using two versions: a user-specified head version and an older, automatically-determined basis version The “recent changes” to be included in the change package were made by starting with the basis version (version 9 in this example) and Keep’ing one or more new versions (versions 10, 11, 12, 13, and 14 in this example).In the AccuRev GUI, the head version of a change package entry is usually identified simply as the “Version”.Note: the Patch command uses the same “recent changes” analysis to determine which changes in the “from” version are to be incorporated into the “to” version.Where should the change package entry for brass.h be recorded? AccuRev already provides a mechanism for keeping track of development activities: the AccuWork issue-management facility. Each task — fixing a bug, creating a new feature, etc. — is tracked by a particular AccuWork issue record. So it makes sense to implement change packages using issue records.Each issue record includes a Changes section that acts as an “accumulator” for versions’ changes. Here’s how the above example of a change package would appear in an issue record’s edit form:
• brass.c: The basis version, 5/10 was created in the user’s own workspace. This indicates that the user promoted 5/10 to the backing stream. AccuRev assumes that this change was for another task, not the one covered by this issue record. Then, the user turned his attention to the current task, creating additional versions up to and including 5/13, the head version.
• chap03.doc: This change began when the user updated his workspace, bringing in version 4/7 of the element (which had originally been created in another workspace, then was promoted to the backing stream). Then, the user created one or more versions in his own workspace, up to and including version 5/11, the head version.
• tools.readme: Similarly, this change began when the user updated his workspace, bringing in version 12/3, originally created in another workspace. The user created one or more versions in his workspace, ending with version 5/9, the head version.Each change package can include at most one entry for a given element. This rule helps to ensure that the changes in a given change package are consistent with each other. See Updating Change Package Entries on page 36.
AccuRev, Inc. |
Phone: 781-861-8700 |
Fax: 781-861-8704 |
support@accurev.com |