On Thu, Jul 30, 2009 at 06:40:00PM +0100, Julian Foad wrote:
> On Thu, 2009-07-30 at 18:05 +0100, Stefan Sperling wrote:
> > On Thu, Jul 30, 2009 at 05:59:23PM +0100, Julian Foad wrote:
> > > Hi Daniel.
> > >
> > > Thanks for your interest.
> > >
> > > Issue #3342 <http://subversion.tigris.org/issues/show_bug.cgi?id=3342>
> > > is not talking about the "G foo1" notifications. It is about the message
> > > that says
> > >
> > > [[[
> > > Summary of conflicts:
> > > Text conflicts: 2
> > > Property conflicts: 1
> > > Skipped paths: 10
> > > ]]]
> > >
> > > Sorry - that's my fault for not being clear when I wrote it. I've just
> > > added a note to the issue to clarify this.
> > >
> > > To fix this, I would change the notifier function in
> > > subversion/svn/notify.c so that it still collects the statistics in
> > > 'nb->text_conflicts' etc., but does NOT call print_conflict_stats() when
> > > it gets an 'update_completed' or 'merge_completed' notification.
> > > Instead, make print_conflict_stats() a public function (named
> > > svn_cl__print_conflict_stats()) so that the top-level update function
> > > (svn_cl__update()) can call it to print the stats when the whole update
> > > is finished.
> > > Then adjust the callers (update, switch and merge) to call
> > > svn_cl__print_conflict_stats() after finishing the update/switch/merge
> > > operation.
> >
> > Why not gather stats entirely inside of libsvn_client so that
> > other clients can also benefit?
>
> That might be useful... but I'm not entirely convinced it would be best.
> The summary stats seem to be quite closely tied to the way the client
> wants to classify the notifications. For example, it records conflicts
> in externals separately from conflicts in non-externals. A different
> client may well not be interested in that particular distinction, but
> may instead want to classify them in some other way such as skipped
> directories vs. skipped files.
>
> I would guess that most clients are GUIs and a GUI would not need
> libsvn_client to provide the stats because it would, I assume, remember
> the actual notification results in a list, and filter or classify them
> however it wants, and then it would just count the elements in its
> list(s). So it seems to me that this kind of summary is rather specific
> to command-line clients.
>
> To move the counting into libsvn_client would be a much bigger change,
> including API change, and Daniel said he's a newbie, so I think just
> changing the 'svn' client would be a good task.
OK. Note that Edmund Wong has been working on this issue, too,
and I told him to do the stat gathering in libsvn_client.
Maybe that is why he hasn't made much progress, given that it
makes the task more difficult -- I gave him bad advice :(
Cc'ing Edmund to make him aware of his new companion Daniel.
Stefan
Received on 2009-07-30 19:47:59 CEST