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

Re: svn commit: r27614

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-11-13 02:52:56 CET

Eric Gillespie <epg@pretzelnet.org> writes:
>> >> +void
>> >> +svn_repos__set_capabilities(svn_repos_t *repos,
>> >> + apr_array_header_t *capabilities)
>> >
>> > Please make these public; any network server needs them, not just
>> > the two we bundle.
>> Sounds reasonable to me. I may give the latter a POOL arg in that
>> case, will think on it and try to DTRT.
> Yes, good idea. How about returning svn_error_t * as well?

I reworked these APIs in r27780.

It turned out there wasn't much point including a POOL argument. Only
the caller could possibly have access to the svn_repos_t's pool
anyway, and in that case it can allocate the capabilities in that pool
too (or copy them over, if necessary, but in practice that would never
be necessary because the caller is only constructing the capabilities
list for the purpose of storing it in the svn_repos_t anyway).

I did make it return svn_error_t *, though, since there's no
workaround for that if we need to return error later.

Oh, and the API for turning a hash table into a capabilities list just
became a private, static helper function in mod_dav_svn. That was the
only RA layer using it, and it was fairly dependent on internals of
how the server stores capabilities internally anyway. It should have
been private from the beginning, once I realized that svnserve
wouldn't use it.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 13 02:53:07 2007

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.