A Change Package Example

The following relatively simple yet realistic example illustrates the benefits of AccuRev change packages in the development environment.

1.	Assume a development environment where one stream is dedicated to enhancements and bug fixes for a “point” release (“Release 4.1”), and a parallel stream is dedicated to the next major release (“Release 5.0”).

2.	In the 4.1 stream, two issues are active: one for an enhancement to a GUI display, and another for a bug fix to the same area of the code:

3.	These issues affect two files. The enhancement (Issue #5) touches both ViewPref.java and DisplayTables.java. The bug fix (Issue #6, which was promoted before the final Issue #5 enhancement changes were promoted) touches only DisplayTables.java.

4.

The team working on Release 5.0 wants to incorporate the changes done by the 4.1 team into their own code. If 4.1 was already completed and released, the 4.1 changes would have already been promoted up to the integration stream (the common parent for the development streams), and the changes would be automatically inherited by the 5.0 stream. However, things do not always work in such an orderly manner in the software development world, so the 5.0 team decides to cross-promote Issue #5 from the 4.1 development stream to one of the workspaces under the 5.0 stream. When you cross-promote an issue, you cross-promote the elements of the change package associated with that issue. So this operation brings the 4.1 versions of ViewPref.java and DisplayTables.java associated with Issue 5 into the 5.0 stream structure. Perform the cross-promote with a simple drag & drop of Issue #5 from the 4.1 stream Active Issues view to the 5.0 workspace:

5.

If this had been a simple cross-promote of changes associated with a single issue, we would be done. But as noted before, software development is rarely simple. Recall that one of the files had also been modified for a bug fix under a different issue. AccuRev detects this complication and automatically displays a diff and merge utility so that you can determine what changes you want to take (see The AccuRev Merge Tool). You decide to take all the changes, including the bug fix, and keep the file. (The example below doesn’t show actual code.)

6.

Finally, the 5.0 team member makes additional changes to one of the files for 5.0, and promotes the files against the original issue (#5). The end result is that Issue #5 is active in both streams, and is not “incomplete” in either stream. (Experienced AccuRev users will note that it is no longer necessary to create separate issues for this scenario as of AccuRev Release 6.0, and that they encounter “incomplete change packages” less often than in the past.)

Note: It is still possible to encounter incomplete change packages. For example, if the cross-promote had not automatically invoked the merge tool, the new version in the 5.0 stream would not have been available to the 4.1 stream, and Issue #5 would have become “incomplete”. How do you fix this? Just cross-promote Issue #5 back to the 4.1 stream after you make your changes.