I (Julian Foad) wrote on 2012-01-25: > 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.
In r1440193 I did that, closing issue #4238. >> 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. I'll tackle that next. - Julian
