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

Re: Apache release compatibility, WAS: RE: svn commit: rev 4239 - trunk/subversion/libsvn_subr

From: Greg Stein <gstein_at_lyra.org>
Date: 2003-01-03 23:12:46 CET

On Fri, Jan 03, 2003 at 01:51:45PM -0800, Justin Erenkrantz wrote:
> --On Friday, January 03, 2003 15:02:11 -0600 Karl Fogel
> <kfogel@newton.ch.collab.net> wrote:
> > It may be moot, because we'll probably need to use http-2.1.x series
> > anyway, due to mod_dav changes (and who knows what else, by then).
> Well, my hope is that we may be able to pull off these mod_dav changes with
> a backport to 2.0 that doesn't break binary compatibility (we added just
> enough of the versioning provider API to -stable that we may be able to
> pull this off). I have no idea whether this is going to be feasible - and
> probably won't until we're done with the required changes.

Ah. Excellent! Glad you got that in. It'll be a big help.

> I'd rather get #773 fixed first and then worry about backporting once we
> get it to work to our satisfaction. We have to fix this bugger - 2.0 or
> 2.1 doesn't really matter. -- justin

Yup, you're right. And I think there is a lot of cleanup that can happen
entirely on the SVN side. There is probably a lot that can be done in how
mod_dav drives the existing API, too.

For example, we can stream one propstat at a time, clearing pools in
between. And that probably won't need an API change.

But SVN really needs to clear some pools somewhere in there. mod_dav
certainly isn't using a hundred megabytes in order to respond to 1000 file
PROPFIND requests. (and pool clears prolly don't need an API change)


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 3 23:12:00 2003

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.