On Wed, Jul 06, 2011 at 12:23:25PM -0400, Paul Burba wrote: > One alternative would be to stop nesting conflicts if merge tracking > is active and treat existing conflicts as obstructions. Using the > existing merge tracking infrastructure for marking skipped subtrees as > untouched by a merge, we could leave the initial conflict and add > subtree mergeinfo on the conflicted path to reflect that the > subsequent merges didn't touch it. For example, in step 4 we could do > this instead: > > 4) Instead of creating a second conflict we skip the existing conflict: > > >svn merge ^^/A A_COPY -c7 > Skipped 'A_COPY\D\H\omega' > --- Recording mergeinfo for merge of r7 into 'A_COPY': > U A_COPY\D\H\omega > G A_COPY > Summary of conflicts: > Skipped paths: 1 > > >svn st > M A_COPY > ? A_COPY\D\H\omega.merge-left.r5 > ? A_COPY\D\H\omega.merge-right.r6 > ? A_COPY\D\H\omega.working > CM A_COPY\D\H\omega > Summary of conflicts: > Text conflicts: 1 > > 5) Mergeinfo is updated on the merge target as expected, but is also > added to the conflicted path, but *only* for the first merge (r6): > > >svn pl -vR > Properties on 'A_COPY': > svn:mergeinfo > /A:6-7 > Properties on 'A_COPY\D\H\omega': > svn:mergeinfo > /A/D/H/omega:6 > > With the change in behavior it is arguably(?) easier to resolve the > first conflict then repeat the merge (where merge tracking sees that > the omega hasn't had r7 merged and applies only that part of the > diff):
What if users run 'svn revert' as part of resolving the conflict? Revert would remove the explicit mergeinfo, so subsequent merges won't try to merge changes for r7 again. So I think we'll need some other approach. We could have 'svn merge' check for conflicts in the working copy upfront and refuse to run the merge unless a special option (--allow-conflicts?) was passed. Like we already do for mixed-revisions.
