On Mon, 2005-02-28 at 23:03 +0100, Peter N. Lundblad wrote:
> Hi,
>
> We need to revise the notification API, i.e. svn_wc_notify_func_t for the,
> guess what, locking branch. We want to notify users when locks get
> defunct during an update. We can't add another action, since this can
> happen at the same time as text changes was updated or something. We
> shouldn't call the notify function more than once per path.
>
> It is not like this is just three or four calls... There are plenty of
> these calls all over the place.
>
> I've got a feeling that we might want to extend this again in the future.
> To make it more extensible, without having to revise it again, I propose:
> - Instead of just adding another argument, move all arguments to a struct.
> Pass a pointer to that struct to the new notify function.
> - REquire that this struct is created bya an svn_wc_notify_args_create (or
> some name), that initialize everything to default arguments.
>
> Then we can add fields in the future without having to revise again.
>
> Also, svn_client_ctx_t is extensible by design. It is possible to add the
> new notify function/baton as new fields. svn_client_create_context could
> init them to a function/baton that forwards to the old function. The other
> alternative is to revise svn_client_ctx_t, leading to revision of all
> client functions. Which do you prefer as the least ugly way? Or do I miss
> an obvious other alternative?
*sigh* I'm OK with this... I just went through the same thing you're
going through as I'm making svn_client_lock and svn_ra_lock take
multiple targets, but I punted and went the route of creating an
svn_wc_lock_info_func_t with an opaque baton as I'm just not up for the
API juggling that you seem so good at. :-)
Anyway, +1.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 28 23:30:33 2005