On 1/24/06, Greg Stein <gstein@lyra.org> wrote:
> On Tue, Jan 24, 2006 at 08:57:27PM -0600, jerenkrantz@tigris.org wrote:
> >...
> > +++ trunk/subversion/include/svn_ra.h Tue Jan 24 20:57:24 2006
> > @@ -1545,6 +1545,12 @@
> > apr_pool_t *pool,
> > apr_hash_t *hash);
> >
> > +/** Initialize libsvn_ra_serf.
> > + *
> > + * @deprecated Provided for backward compatibility with the 1.1 API. */
> > +svn_error_t * svn_ra_serf_init (int abi_version,
> > + apr_pool_t *pool,
> > + apr_hash_t *hash);
>
> No need for this. There are no programs built against the 1.1 API that
> will be calling this function.
I thought so too, but there's this nice todo in ra_loader.c:
* ### todo: Any RA libraries implemented from this point forward
* ### don't really need an svn_ra_NAME_init compatibility function.
* ### Currently, load_ra_module() will error if no such function is
* ### found, but it might be more friendly to simply set *COMPAT_FUNC
* ### to null (assuming COMPAT_FUNC itself is non-null).
So, I'm not sure setting compat_init field to NULL would actually
work. There are some files in trunk that still use
svn_ra_get_ra_library. If they were to request the 'http' or 'https'
scheme when ra_serf was loaded instead of ra_dav, an error would be
returned. If a program worked with svn 1.0 that expected 'http', it'd
fail if serf were included unless the compat init was present...
> I would suggest that all of these stubs to an abort(). Thus, while
> you're developing, if one is called unexpectedly, then you'll see it
> right away.
Fair enough.
> You could also replace these with NULL, until they're written.
Yes, but I wanted to walk through the functions myself and get the
prototypes in there now so that I know what functions I need to
implement.
> > +/* Compatibility wrapper for pre-1.2 subversions. Needed? */
>
> I'm not sure how this wrapper works, but yah: it might be needed. This
> would allow a 1.0 or 1.1 client to use the 1.x SVN libraries to talk
> to a repository via serf.
I tried to not include these, but the implementation for the new init
function is also in that wrapper template. Modulo the reasons above
to keep the compat_init function in there, without the compatibility
wrapper, we'd have to 'roll' our own init function for the new API as
well.
Thanks. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 25 05:31:58 2006