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.
Received on 2011-07-06 18:36:23 CEST