Re: Bug in conflict summary after partial resolution

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.
>
> I'll take this one.  There's a bunch of stuff to sort out, here; marking
> both conflicts as resolved at the same time is only one of the bugs.

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.

- Julian

>>  Example:
>>
>>  $ svnadmin create repo
>>  $ svn co file://$PWD/repo d1
>>  $ svn co file://$PWD/repo d2
>>  $ cd d1
>>  $ echo a > f; svn add f; svn ps p x f
>>  $ svn ci -m m
>>  $ cd ../d2
>>  $ echo b > f; svn add f; svn ps p y f
>>  $ svn up
>>  Updating '.':
>>  CC   f
>>  Updated to revision 1.
>>  Conflict for property 'p' discovered on 'f'.
>>  Trying to add new property 'p'
>>  but the property already exists.
>>  <<<<<<< (local property value)
>>  y=======
>>  x>>>>>>> (incoming property value)
>>
>>  Select: (p) postpone, (mf) mine-full, (tf) theirs-full, (q) quit,
>>          (h) help: p
>>  Conflict discovered in file 'f'.
>>  Select: (p) postpone, (df) diff-full, (e) edit, (m) merge,
>>          (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: mc
>>  Resolved conflicted state of 'f'
>>  Summary of conflicts:
>>    Text conflicts: 0 remaining (and 1 already resolved)
>>    Property conflicts: 0 remaining (and 1 already resolved)
>>  $ svn st
>>  MC      f
>>  ?       f.prej
>>  Summary of conflicts:
>>    Property conflicts: 1
>>
>
Received on 2013-04-24 17:45:02 CEST