Re: Bug in conflict summary after partial resolution

I (Julian Foad) wrote:
> I (Julian Foad) wrote on 2013-04-15:
>> Mattias Engdegård wrote:
>>> If a file has both text and property conflicts, only resolving one of
>>> them leads to an incorrect conflict summary message.
[...]
> 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.

And I nominated it for back-port.

> 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.

How hard can it be to add full support for marking individual properties as resolved?  I see two distinct levels to "full support".

Firstly, to fix the bug in interactive resolution, support is needed in libsvn_wc to ensure that when a conflict resolver callback (called from libsvn_wc/conflicts.c) returns any kind of 'resolved' result for a property conflict, the WC should mark only that specific property as resolved.  That would be enough to fix the interactive conflict resolution.  I'm looking at how feasible this might be.

Secondly, we might want to enhance the 'svn resolve' UI to allow specifying a particular property.  I see that as being a comparatively minor enhancement.  (We could also add such an option to the svn_client_resolve() API, but the API can always be given a callback function that only resolves conflicts on a specific property so there is no need for the API to expose such an option explicitly.)

The best idea I have *short of* getting "full" support by fixing libsvn_wc is to make 'svn' track how many of the propery conflicts you resolved, and if you resolved some but not all of them then print a warning that all of the properties were marked as resolved.  That's not great but would be simple to implement and would improve the user experience a bit.

It might be possible to leave all of the property conflicts on that node *unresolved* if they're not all resolved, which is probably a better user experience, but I'm not sure how we'd do that purely in the client.  Once the callback has returned any kind of "resolved" result for one property, libsvn_wc currently marks all prop conflicts on the node as resolved before calling the callback for the next property, and I don't know of any good way to avoid that.

> 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.

r1471759 on trunk prints a summary of conflicts before interactive resolving.

I haven't proposed this for back-port.  We could do if folks want it.

> 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.

I'm not planning to tweak the wording at the moment.

- Julian
Received on 2013-04-25 16:15:46 CEST