[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Notification API

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-03-01 08:52:00 CET

On Mon, 28 Feb 2005, Brian W. Fitzpatrick wrote:

> On Mon, 2005-02-28 at 23:03 +0100, Peter N. Lundblad wrote:
> > 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?
I still want an opinion about the above paragraph.

> *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

Since we have to revise the notify API anyway, I think this
svn_wc_lock_info_func_t should go again.

> API juggling that you seem so good at. :-)
Since you really needed it first (but shamelessly worked around it:-), I
offer you the opportunity to be the one hero who did this...

> Anyway, +1.
Thank you for the support...

Seriously, I'll do it if you don't. It will take some days, though since
my time is limited currently.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 1 09:00:37 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.