On Wed, 2005-07-27 at 23:27 +0100, Nix wrote:
> > I gave up trying to follow the auth stuff. However, at around line
> > 720 svn_ra_dav__open calls svn_auth_set_parameter and passes things
> > allocated from its pool and these get stored in the hash passed via
> > the callbacks argument, so it looks like the hash could well have a
> > longer lifetime than the dav session.
Yuck. Data stored within auth_baton should be allocated in the same
pool as auth_baton, according to our general philosophy, and there's no
elegant way to make that happen when the data being stored is a void
pointer. We could add a call to retrieve the auth baton's pool,
perhaps.
Failing that, cleaning up the parameters in a pool cleanup function
seems prudent. Like Philip, though, I'm a little lost as to how the
auth system works. Why is ra_dav responsible for auth parameters with
names that aren't clearly within an ra_dav namespace?
> > Interesting, what do you see as the advantage of --enable-dso?
Some of our package distributors use it to manage dependencies. By
moving mod_dav_svn into its own package, for instance, the core
Subversion package doesn't have to depend on httpd. Similarly for
libsvn_fs_base and Berkeley DB.
> Simply that I use svnserve a lot more than ra_dav, and my svn server
> is so small that keeping the number of shared libs loaded down counts
> (or at least it counted in the days before prelink).
I'm surprised that this would matter. Loading a shared library doesn't
necessitate actually reading in the whole thing from disk into memory,
although I suppose it does mean resolving from symbols.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 28 01:05:07 2005