RE: svn commit: r1350917 - in /subversion/trunk/subversion: include/svn_wc.h libsvn_wc/conflicts.c svn/notify.c

> -----Original Message-----
> From: stsp_at_apache.org [mailto:stsp_at_apache.org]
> Sent: zaterdag 16 juni 2012 14:58
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1350917 - in /subversion/trunk/subversion:
> include/svn_wc.h libsvn_wc/conflicts.c svn/notify.c
>
> Author: stsp
> Date: Sat Jun 16 12:57:36 2012
> New Revision: 1350917
>
> URL: http://svn.apache.org/viewvc?rev=1350917&view=rev
> Log:
> Make the conflict resolver send a conflict summary to the caller, before
> invoking the conflict callback.
>
> This will eventually allow 'svn' to print the conflict summary before the
> interactive conflict resolution callback is invoked. This summary is currently
> printed after the callback was invoked on each conflict, which isn't helpful.
>
> This commit has no visible behaviour change yet, as this would require all
> operations to delay conflict callback invocation, which has currently been
> implemented only for 'update'.

Why does libsvn_wc do the counting of the conflicts?

All the conflicts are already notified to the notification callback, so the counting itself could just be handled by svn (as far as I know the only client that uses these conflict stats in this way).

If some higher layer (such as libsvn_client) combines operations, the calculations done by libsvn_wc won't provide the necessary results.

I think we have some precedent of providing notification actions where we need these notifications, but I don't think libsvn_wc should do the counting.

Maybe the notification could be used more generic as something like _before_conflict_resolving, or something.

        Bert
Received on 2012-06-16 17:35:44 CEST