A patch is a set of versions of a text-file element, whose changes have been incorporated into another version of the element with the
Patch (or
Patch From) command. Informally, a patch consists of one user's "recent changes" to the element. The patch facility was designed to easily transfer to another development context the set of changes that were made to an element for a particular development task.
A change package contains a set of entries, each of which (usually) has the same form as a patch. But change package entries can be
modified (added to) after they are first created. Such modified entries don't fit the "recent changes" description; rather, a change package entry can act like an accumulator, recording
all the changes made to the element to fulfill a particular development task. The change package facility was designed to track exactly what element-by-element changes go into the bugfix or feature that the issue record describes.
The Patch command creates a new version in a workspace. This version is termed the
head version of the patch. AccuRev automatically determines a corresponding
basis version by scanning backward through the element’s
ancestry. The basis version is the most recent version that was either:
Example 1: If patching from version
wheat_dvt_john/4, AccuRev determines that John's "recent changes" to this element started with version
wheat_mnt_john/1. (John used
Send to Workspace to bring this "mnt" version into his "dvt" workspace.)

Example 2: If patching from version
wheat_dvt_mary/5, AccuRev determines that Mary's "recent changes" to this element started with version
wheat_dvt_john/14. (John created that version and promoted it to backing stream
wheat_dvt. Mary brought the version into her workspace with an update.)

Example 3: If patching from version
wheat_dvt_mary/14, AccuRev determines that Mary's "recent changes" to this element started with version
wheat_dvt_mary/11. (Mary created that version -- maybe for the same development task, but maybe not -- and promoted it to backing stream
wheat_dvt. Then she continued working on the element.)

In the Version Browser, a version created by
Patch is connected to the "patch from" version with a
dashed red line. Selecting this version highlights the versions in the patch.

Each issue record in an AccuWork
issue database includes its own change package. A change package can contain entries for any number of elements -- but only one entry per element. The elements must belong to the same depot as the issue database.
Each change package entry is similar to a patch -- it consists of all the element's versions between a designated head version and basis version. This is a more general structure, because there is no "one user's recent changes" restriction to the scope of versions. The only restriction to is that the basis version be an
ancestor of the head version -- so that the set of "between" versions is well-defined.

In the Changes subtab of an issue record's
edit form (and equivalently, in a
Stream Issues tab), a change package is displayed in a table, each row showing one change package entry. Example:

Typically, a new change package entry is exactly like a patch -- the
Send to Issue command and the
change package-level integration between AccuRev and AccuWork create an entry whose basis version is automatically selected in the same way as the
Patch command. When the entry is later modified, it assumes the more general structure.
Change packages are designed to track ongoing changes to elements, not just a single set of changes. This means there will be times when you want to add a change package entry for a particular element, but an entry for that element already exists in the change package. In such situations, AccuWork attempts to combine the new entry with the existing one, producing an updated entry that includes all the changes. (Recall that there can be at most one entry for a given element in a given change package.)
To help explain how AccuWork performs "change package arithmetic" to combine and update entries, we'll use a simple notation. Suppose a change package entry contains the set of an element's versions defined by these specifications:
We'll use the ordered pair [B,H] to indicate this change package entry.
When AccuRev tries to combine the change [B,H] and the change [
J,X] into a single change package entry, it detects that version
H and version
J are not the same, but that
H is a direct ancestor of
J. Thus, there is a simple "gap" in the potential combined change package entry (in this example, consisting of your colleague's versions 9 and 10).
An issue record's change package differs from its user-defined fields (Status, Severity, Description, etc.). When you change the value of a user-defined field, the
Save button is enabled in the edit-form toolbar. You can discard the change by closing the edit-form tab without performing a
Save. But the commands that create, modify, and delete change package entries take effect immediately. There is no way to discard such changes, and there is no need to
Save them. (You can
Remove a change package entry altogether, but you can't undo the adding of a new change to an existing entry.)
Change packages don't participate in the AccuWork's issue-history capability. Modifications to a change package don't appear in the
Issue History subtab of an edit form (although you can use the
Change Package History feature described above). And if you use this subtab to view an "old" version of an issue record, the Changes subtab still displays the current contents of the change package, not the "old" contents.
It is possible to end up with changes that are not associated with any issue. For example, somebody might decide that a file does not belong to an issue and remove it from the change package. Or somebody might decide to promote a file in a backing stream, without associating it with an issue. If such element versions are not associated with any issue, they are considered
unaffiliated (sometimes called "dark matter"). Such element versions can lead to confusion, so AccuRev provides a way to view unaffiliated changes in the GUI.
If any unaffiliated changes exist in the stream, the issue table gains an extra row labeled "NONE". If your table layout includes the ShortDescription column, you will also see "UNAFFILIATED CHANGES" in the row. Clicking this row displays an error message informing you that "This issue cannot be opened because it doesn't really exist".
There are two ways to deal with unaffiliated changes: short-term and long-term. If you are working under a deadline and just need a way to deal with these files so that they don't keep you from promoting everything in a stream, you can, for example, just
Promote by File without associating the files with an issue. However, this is just a temporary fix, and you are just perpetuating the problem and pushing it further up your streams.
The long-term, correct solution is to determine why these changes are unaffiliated, and depending on how they got into this state, attempt to correct them. Typically there are three ways that an unaffiliated change may occur:
Once you have committed to working with change packages, you should never do Promote By File operations without associating the files with an issue. These can result not only in unaffiliated changes, but they can also cause incomplete change packages which are another source of confusion (see the "Incomplete Change Packages" chapter of the
AccuRev Technical Notes manual for more information).
In any case, the best way to proceed is to associate the unaffiliated change with an issue, either by using
Send to Issue for an existing issue, or by creating a new issue to handle this specific change.
From the resulting display, you can right-click the unaffiliated elements, explore their history, and then take appropriate actions to correct their unaffiliated status. For example, you can use
Send to Issue and then promote, or promote the files to an issue while promoting from this stream to its parent.
