When you want to create change package entry for a particular element, but an entry for that element already exists in the change package, AccuRev attempts to combine the new entry with the existing one. (Recall that there can be at most one entry for a given element in a given change package.) This produces an updated entry that includes all the changes.To help explain how AccuRev 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.Now, suppose a new change is to be combined with the existing change package entry [B,H]. There are several cases, each handled differently by AccuRev:
• Case 1: [B,H] + [H,X] — This simple case typically arises when you think you’re done with a task and record your work as change package entry [B,H] — but it turns out that more work on the same element is required. So you (or a colleague) start where you left off, with version H, and make changes up to version X. Then, you want to incorporate the new set of changes [H,X] into the same change package.In this case, it’s clear that the two series of changes can be viewed a single, uninterrupted series — starting at version B and ending with version X. That is:[B,H] + [H,X] = [B,X]Accordingly, AccuRev updates the change package entry automatically — keeping B as the “Basis Version” and changing the “Version” from H to X.
• Case 2: [B,H] + [J,X] (where H is an ancestor of J: “change package gap”) — This case typically arises when you do work on a task at two different times, and someone else has worked on the same element in between.In this example, a colleague updated her workspace to bring in your original changes, created versions 9 and 10 in her workspace, and promoted her changes. You then updated your workspace to bring in her changes, and made a new set of changes.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).Probably, your colleague was not working on the same task when she made her changes. (If she had been, she would have added her changes to the same change package, as in Case 1.) On the other hand, it’s probably OK to include the entire, uninterrupted series of versions [B,X] in your change set — this includes both your original changes and your new changes (and, harmlessly, your colleague’s changes, too).Accordingly, AccuRev can “span the gap” between the two change set entries, in order to create a single, combined entry.
• Case 3: [B,H] + [K,X] (where H is not an ancestor of K: “change package merge required”) — This case typically arises when developers in workspaces that do not share the same backing stream try to use the same change package. There is no simple “gap” between the existing change package entry and the new one — which means there is no way to combine them into a single change package entry, according to definitions in Complex Change Package Entries on page 35.AccuRev signals this situation with a “change package merge required” message, and cancels the current operation. You can remedy this situation by performing a merge at the element level. (There is no merge operation defined at the change package level.) In the example above, merging version H and version X would create a new version; a change package entry with the new version as its head can be combined with the existing entry.
AccuRev, Inc. |
Phone: 781-861-8700 |
Fax: 781-861-8704 |
support@accurev.com |