Change propagation practices explore how changes made to one version of the application are migrated to other living versions of the application.
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.