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.)
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-03-18 20:36:23 CET