There are cases where a reintegrate merge into a sparse working copy causes
problems in subsequent merges.
Kevin Cathcart reported one such problem here:
http://mail-archives.apache.org/mod_mbox/subversion-users/201405.mbox/%3Cloom.20140515T222101-91%40post.gmane.org%3E
Quote:
"""
I've found what really looks to be a buggy edge case with
the automatic merge feature of 1.8.X which can occur if:
* a partial (reintegrate-like) merge into a sparse working
copy is committed
* and then immediately followed by merging the same branch again
into a full working copy.
By a partial merge I specifically mean that the sparse working
copy was missing a target of the merge.
Here is a diagram of the branching in question:
3-X4------6-+---+ ^/branch/some_feature
/ / & \
1-2-+------Y5-+-----7---8 ^/trunk
(Obviously the ampersand indicates the partial merge due
to sparse WC. Also two commits are showing a name along
with a revision number).
With that particular pattern I see two anomalies
that do not occur if the order of commits X and Y are
reversed:
3----X5---6-+---+ ^/branch/some_feature
/ / & \
1-2-+---Y4----+-----7---8 ^/trunk
"""
The important part here is "that [problems] do not occur if the order of commits
X and Y are reversed". This seems odd, and should be investigated.
Bug
Major