Stefan Sperling wrote:
> I filed the issue. I think I had in mind that we'd store multiple
> conflicts, but I'm not quite sure.
>
> I agree with your plans to deal with the non-interactive --accept case.
>
> I have one concern about the interactive case where no --accept option
> was passed, which we might want to consider addressing as well for 1.8.
>
> Currently, 'svn merge' errors out as follows if one of the ranges merged
> in a multi-range merge conflicts.
...
> That's fine and expected. It is the same as the --accept=postpone
> behaviour you are proposing.
>
> But it seems what's missing is to continue the merge in case no
> conflicts are left after the resolver returns. Consider:
>
> $ svn merge -c3,4 ^/trunk
> --- Merging r3 into '.':
> C alpha
...
> Conflict discovered in file 'alpha'.
...
> Select: (p) postpone, (df) diff-full, (e) edit, (m) merge, (r) resolved,
> (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: r
> Resolved conflicted state of 'alpha'
...
> svn: E155015: One or more conflicts were produced while merging r2:3 into
> '/tmp/svn-sandbox/branch' --
> resolve all conflicts and rerun the merge to apply the remaining
> unmerged revisions
>
> So the conflict has been resolved, but 'svn merge' stops anyway.
> I think it should continue merging further ranges instead.
>
> I don't think we should continue the merge in case any conflicts are
> left in the working copy, of course
OK, that all sounds good. I'll try to make it happen.
- Julian
Received on 2013-01-25 15:00:40 CET