On 9/19/06, Vlad Georgescu <vgeorgescu@gmail.com> wrote:
> On 9/19/06, Philip Martin <philip@codematters.co.uk> wrote:
> > "Garrett Rooney" <rooneg@electricjellyfish.net> writes:
> >
> > > Ok, one catch... ra_svn_sasl.h depends on ra_svn.h for one constant
> > > (SVN_RA_SVN__READBUF_SIZE). Now there's no way in hell that
> > > SVN_RA_SVN__READBUF_SIZE should live in ra_svn_sasl.h, and similarly,
> > > I'm not all that thrilled about ra_svn.h living in private/, since
> > > it's really not used outside of libsvn_ra_svn. Any thoughts on a
> > > proper home for that constant?
> >
> > Ahh, the 4096 I queried in the original patch :) How about getting rid
> > of SVN_RA_SVN__DEFAULT_SECPROPS and using
> >
> > void svn_ra_svn__default_secprops(sasl_security_properties_t *secprops);
>
> Good idea. Unfortunately, this isn't the only instance of svnserve
> sticking its nose into libsvn_ra_svn's business. In
> svnserve/sasl_auth.c I accidentally used conn->sock directly, but
> svn_ra_svn_conn_t is supposed to be opaque to the server. This worked
> precisely because ra_svn_sasl.h includes ra_svn.h, and that's where
> svn_ra_svn_conn_t is defined.
>
> Anyway, the attached patch attempts to fix both issues.
Heh. That's remarkably like the patch I was half way through writing.
I committed it with some tweaks in r21560, the main change being that
I called the new header private/ra_svn_sasl.h instead of
private/svn_sasl.h, since the code really is ra_svn specific.
Thanks Vlad!
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 19 23:38:34 2006