Account for reflected revisions when performing cyclic merges. For
example: trunk is branched, then modified, and the branch is brought
up to date with trunk in a manner which requires some conflict
resolution (e.g. additional changes on top of the revisions merged),
then the branch is modified, then the branch is merged to the trunk.
To avoid repeated merging of changes to trunk, only the modification
to the branch should be applied to trunk. That is, both the changes
from the conflict resolution performed after the merge from trunk to
branch (but not the revisions from the merge itself), plus the
additional change on the branch, should be merged back to trunk.
To accomplish this, we need to be able to be able to:
* Identify revisions which are commits of merges.
* For those revisions, differentiate between changes from revisions
already reflected by (e.g. present in) the target, and additional
changes which were not part of a merge.
Typically, VC systems handle this by recording two or more parents
for a change set, and applying graph algorithms to handle the
mechanics of determining what to merge. See the following thread for