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

Re: rfc on structure changes

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-09-21 20:47:14 CEST

On Wed, 21 Sep 2005, Madan U Sreenivasan wrote:

> This is a request for modifying the way certain publicly available
> structures are written. The below is the only example am able to give...
> but its possible that there are more like this...
> svn_ra_plugin_t structure in subversion/include/svn_ra.h. I need to
> change a parameter of the svn_commit_callback_t member.

You don't need to change anything in that struct:-) It is deprecated and
not used anymore except for backwards compatibility. The internal
svn_ra__vtable_t can be changed at will.

> To do this, I have to
> - deprecate svn_ra_plugin_t with svn_ra_plugin2_t
> - replace/deprecate all functions using svn_ra_plugin_t
Yes, it got cumbersome. That's the reason for revving the whole RA API.

> An easier way to do such a change would be to deprecate only the
> member that needs to change with a new member, added at the bottom.

That has happened before. See r11155. It introduced a get_log2 function.
As someone said, you can do this in certain situations.
> I know these are not the best ways to achieve what is required here.
> I would like start a thread/issue to discuss and implement the changes
> required to make life easier for us in future.

Trying to make it easier to extend APIs in the future is a good idea IMO,
if it can be done without cluttering the current API (like adding dummy
arguments "just in case" or such things). One way to do this is by
providing a constructor as Branko said. But, we are forgetting about it
all the time, so keeping an eye on this is good...


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 21 20:48:44 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.