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.