7. Change Propagation

Change propagation practices explore how changes made to one version of
the application are migrated to other living versions of the application.

7.1. Merge branch with the trunk after release

After each release from a branch, the changes made to the branch
should be merged with the trunk. This ensures that all the bug fixes made
to the patch release are properly incorporated into future releases of the
application.

This merge could potentially be time consuming depending on the amount
of changes made to the trunk and the branch being merged. In fact, it will
probably result in a lot of conflicts in CVS resulting in manual merges.
After the merge, the trunk code base must be tested to verify that the
application is in proper working order. This must be kept in mind while
preparing the project schedule.

In the case of changes occurring on branches for a long period,
these changes can be merged to the main branch on a regular basis even
before the release is made. The frequency of merge is done based on certain
logical points in the branch's evolution. To ensure that duplicate merging
does not occur, the following practice can be adopted.

In addition to the branch tag, a tag called {branch_name}_MERGED
should be created. This is initially at the same level as the last release
tag for the branch. This tag is then "moved" after each
intermediate merge by using the -F option. This
eliminates duplicate merging issues during intermediate merges.