On Thu, Jul 30, 2009 at 07:15:04PM +0100, Julian Foad wrote:
> Stefan Sperling wrote:
> > 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 :(
>
> Oh... I didn't remember that.
>
> The information coming up from libsvn_client is "here are notifications
> of all the things happening". I think it would be wrong to make
> libsvn_client say "and also here is some summary information about those
> notifications, classified in a particular way".
The way I saw it was that notification callbacks exist to print
notifications. They don't exist to keep track of what happened
during the entire operation. That's what the batons are for,
and there is a baton of type svn_wc_traversal_info_t which has
precisely the scope we need.
I'm quoting a mail I sent to Edmund about it below.
I agree that the approach you suggested is probably simpler, though.
Stefan
====
So, what we'll do is:
1) We'll move the conflict counters (see struct notify_baton in
svn/notify.c) from the svn client's notification baton into the
svn_wc_notify_t struct.
2) We introduce a new notification action. Right now, we have
svn_wc_notify_update_completed, but that is called for each
update target individually (see svn_client__update_internal
in libsvn_client/update.c). Rather, we want a notification that
says "the whole operation has completed and here are the combined
stats I have collected for you for every target."
So we could add a new action like svn_wc_notify_conflict_stats.
This notification should be issued by svn_client_update3(), after
processing all the targets (see the "for (i = 0; i < paths->nelts;
++i)" loop in svn_client_update3()). When the notification is made,
the stats the library collected during the operation are added
to the new counters we added to svn_wc_notify_t in step 1), and
passed to the client. The client can then read the stats.
I'll leave it to you to figure out where to issue the notification
for merge. But note that it would suffice for now to just focus on
update. Once that is solved, solving the problem again for merge
should be fairly easy.
3) During update, and merge, whenever the client library notifies
the client about a conflict, we increment the conflict stats.
The stats need to be stored somewhere with sufficient lifetime
so that they survive the whole operation. Local variables in
svn_client_update3() (and the equivalent for merge) might be
a good choice for storage. However, local variables aren't that
useful for gathering the stats, because the stats will be gathered
way down in the call chain (in libsvn_wc/update-editor.c, for update).
There is this interesting thing called svn_wc_traversal_info_t,
which is used during an update to gather and summarise information
about externals. It could easily be extended to gather conflict
stats, too. We'll just need to add conflict counters to it.
The traversal info is allocated in svn_client__update_internal(),
and passed down the call chain, until it eventually ends up
in the edit_baton of libsvn_wc/update-editor.c. This is the
perfect spot to collect conflict stats, because we also issue
notifications from there.
Because svn_client__update_internal() operates on a single target,
we can use a traversal info to gather stats for one target only.
But that's fine, and no worse than the current situation.
In addition, we could pass pointers to the local variables we
have in svn_client_update3() down to svn_client__update_internal(),
which could then add the per-target stats to the overall stats
maintained in the local variables of svn_client_update3().
So this is the high-level description of the process for update.
For merge, things might end up being a bit different, because most
of the merge logic is in libsvn_client/merge.c, which also handles
notifications. We won't need a traversal info, for example.
Instead, we can tweak any non-public functions inside libsvn_client/merge.c
to our liking so that we can gather conflict stats.
But again, it's enough if you focus on update, first.
Received on 2009-07-30 20:29:07 CEST