Greg Hudson wrote:
> That's probably more churn that is really necessary here, since the new
> feature isn't needed by existing functions. So what I would do is make
> up a new name for the extended svn_repos_authz_func_t (as opposed to
> svn_repos_authz_func2_t, since that name would imply that
> svn_repos_authz_func_t is deprecated) and make the commit editor use
> that. Then you can leave the existing APIs alone.
I can do that, but this also poses a problem: if I introduce a new
callback type, this also has to be supported through compatibility for a
presumably long time. So we'd be introducing two confusingly similar
but different callback prototypes, and keeping them until compatibility
can be broken, which is a long way away. Is it really worth putting up
with all this bother and potential for confusion in the future, rather
than go through a temporary (albeit quite large) bother and revv both
callback and dependent APIs ? The way I see it, that way compatibility
will still be preserved, and while it will cause a lot of revving for a
fairly stupid reason, it will have the advantage of maintaining an API
that is free of history-induced confusions.
What do you think?
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 30 02:10:03 2005