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

Notification API

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-02-28 23:03:52 CET


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?

//Peter the API revisor:-(

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:02:43 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.