C. Michael Pilato wrote:
> On 03/15/2013 06:03 PM, Julian Foad wrote:
>> NOTIFICATIONS CHANGED
>>
>> As I mentioned in my "Conflict resolver callback design" email,
>> doing this does mean that the notification receiver will get a 'C'
>> (conflict) notification for every conflict even if that conflict is going to be
>> resolved to a pre-determined choice. In terms of the 'svn' client and
>> the 'svn merge' command, this means that 'svn merge
>> --accept=[mine-full, etc.]' will, if we don't take further action, print
>> something like in this example:
>>
>> [[[
>> --- Merging r3 through r4 into 'merge_tests-135/A2/mu':
>> C merge_tests-135/A2/mu
>> --- Recording mergeinfo for merge of r3 through r4 into
>> 'merge_tests-135/A2/mu':
>> G merge_tests-135/A2/mu
>> Resolved conflicted state of 'merge_tests-135/A2/mu'
>> --- Merging r6 through r8 into 'merge_tests-135/A2/mu':
>> U merge_tests-135/A2/mu
>> --- Merging r10 through r11 into 'merge_tests-135/A2/mu':
>> U merge_tests-135/A2/mu
>> --- Recording mergeinfo for merge of r5 through r11 into
>> 'merge_tests-135/A2/mu':
>> G merge_tests-135/A2/mu
>> Summary of conflicts:
>> Property conflicts: 1
>> ]]]
>>
>> I think if this was changed to print a slightly different summary,
>> something like...
>>
>> [[[
>> Summary of conflicts:
>> Property conflicts: 0 (and 1 already resolved)
>> ]]]
>>
>> ... then it would be fine. I don't see that the interleaved
>> 'Resolved ...' line is a problem.
>>
>> Do others agree?
>
> The point of the summary section is to draw attention to details that might
> have whizzed by the screen. Given that, I agree it's a bit misleading to
> alert the user to a problem which may not really be a problem any longer.
> So yeah, a change such as what you've suggested makes sense to me.
>
> (Sorry, no feedback on your actual patch.)
I have committed a complete fix, with the Summary of Conflicts as discussed here, in <http://svn.apache.org/r1459012>.
- Julian
Received on 2013-03-20 20:39:03 CET