A 'sync' automatic merge (that is, an automatic merge in the same direction as
the previous one) correctly skips source revisions that have been cherry-pick
merged to the target. However, it does not correctly account for any target
revisions that have been cherry-pick merged to the source.
In the following diagrams, 'o' is an original change, 'x' is a full merge, 'c'
is a cherry-pick merge.
Example Cherry1:
# A (--o------o--[o]----o---
# ( \ \ \
# B (---o--x---------c-----x
# 2 34 5 67 8 9 10 11
In example 'Cherry1', revision 8 on the source branch A has been cherry-pick
merged to the target branch B. The final automatic merge (A10 -> B11) correctly
avoids re-merging change A8.
Example Cherry2:
# A (--o-------------c--o---
# ( \ / \
# B (---o--x---o-[o]-------x
# 2 34 5 67 8 9 10 11
In example 'Cherry2', revision 8 on the target branch B has been cherry-pick
merged to the source branch A. The final automatic merge (A10 -> B11) does not
work correctly: it includes A9 in the set of changes being merged, and because
the change represented in A9 has already been made on the target branch (in B8),
this re-applies the equivalent change to B which creates conflicts.
Example Cherry3:
# A (--o--------------c--o----
# ( \ / \
# ( \ / \
# B (---o--o-[o]-x-/---------x
# \__/
# 2 34 5 6 7 8 9 10
In example 'Cherry3', the topology is different but the behaviour is the same as
in example 'Cherry2'.
This has been the case from version 1.5 (when merge tracking was introduced) to
the current 1.8-dev state of trunk.
Bug
Major