Re: Bug in conflict summary after partial resolution
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 24 Apr 2013 16:44:08 +0100 (BST)
I (Julian Foad) wrote on 2013-04-15:
The Summary of Conflicts says both the text and prop conflicts on this node were resolved, when really only the text conflict was resolved. What's happening is an svn_wc_notify_resolved notification causes us to assume (in svn/notify.c) that all conflicts on that path are resolved.
We can fix this in a number of ways. We could tell the 'notify' handler when we're resolving a prop or text conflict, so that it knows exactly what each 'resolved' notification refers to. Or the notification handler could query the resolved node to see if any conflicts on that node still remain. Or we could change the notification system to be more specific -- but that's too deep a change to make now for 1.8.
The solution I'm implementing is to make the conflict resolver callback decrease the counters when it resolves a conflict, rather than using the 'resolved' notification to do that. The resolver callback knows what kind of conflict it is resolving.
Fixed in r1471490.
There is a second bug, closely related. If there are multiple prop conflicts on the same node, they all get marked as resolved as soon as you request any one of them to be marked as resolved. There is incomplete API support for marking individual properties as resolved so that may be hard to fix.
As an enhancement, the Summary of Conflicts could usefully be printed *before* we start interactive resolution, to give the user an idea of how much work is involved. This is pretty much the subject of issue #3497 "auto merge as much as can; then print summary, then go into conflict resolution", <http://subversion.tigris.org/issues/show_bug.cgi?id=3497>. If we do that, I think we should still print a summary afterwards as well.
Another minor observation. I wonder if some people will find the conflict summary wording to be a little bit unclear or misleading: "Property conficts: 1" means property conflicts in one node, although there could be 3 different properties in conflict on that node. And some people might even think "Text conflicts: 2" means two hunks, whereas it means two files and there might be several hunks in conflict in each file. I regard this as a rather minor UI usability issue, but it's not exactly hard for us to make it a bit clearer.
This is an archived mail posted to the Subversion Dev mailing list.