On Thu, Jul 11, 2002 at 12:17:26PM -0700, Justin Erenkrantz wrote:
> On Thu, Jul 11, 2002 at 01:52:21PM -0500, Karl Fogel wrote:
> > Issue #749 -- revamping WC operations to enforce lock/log policies via
> > an access_baton, also caching entries lists -- is not officially
> > marked as Alpha, but would be nice to get done for Alpha (Monday!).
>
> If the baton starts getting passed around soon-ish (say by this
> weekend), I can try to have the caching in. I know what has to be
> done, I just don't know how the API will shake out.
Also, consider whether there is a partial solution that gives you the 80%
bang. (although I've never been in favor of hacks to meet a deadline; I'm
just commenting on the possibility that you might have a dev plan that meets
your needs and is "nice" at the time we snapshot)
> > 751: need an svn-config file
> > ==> Ben and I are planning to take a look at this tomorrow. BUT,
> > if someone wants to do this, go for it! Just take a look at
> > apu-config for example, and post with questions. We'd love
> > to be able to concentrate on issue #494 and friends :-).
>
> I can do this. Do you want svn-config to tell you anything more than
> what {apr|apu}-config says?
Nope. And even simpler since there is no Expat to worry about.
> IIRC, Greg was mentioning also to
> integrate with pkg-config. My take is that pkg-config isn't going to
> be installed at enough places to warrant anyone using that.
Separate issue. And Jon Trowbridge said that he would work on this one. As a
precursor to a subversion .pc file, he said that he wants .pc files for APR
and APRUTIL. Thus, it will be a bit longer before we see .pc files.
And I'm with Garrett on this: svn-config will be handy without needing the
pkgconfig framework.
> > 773: PROPFIND on large dir takes excessive memory/time
> > ==> Greg Stein will fix this if he has time. It's a mod_dav
> > (not even mod_dav_svn) issue, and it could conceivably get
> > pushed to Beta, as it's more a performance than correctness
> > issue.
>
> I think this is about as resolved as it will be until resource->pool
> gets fragmented in mod_dav.
The memory issue, yes. However, we can solve the latency problem by flushing
each "response" down the output stack as they are generated. Currently,
mod_dav buffers the entire response.
>...
> Hopefully, with my recent patches to mod_dav_svn, we should be a bit
> better off than before - perhaps enough so that we can delay this
> to beta. -- justin
Yes, we definitely could, and the Chicago guys even suggested moving this
issue to beta. I asked that it remains in alpha as a marker for the Apache
work that I'd like to do (unless you beat me to it :-) to reduce the
latency. Once I fix the latency, then we'll shift the issue to beta for
further resolution.
(note that changes *will* occur within mod_dav_svn -- the mod_dav backend
API needs to pass temp pools)
Cheers,
-g
--
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 Thu Jul 11 22:31:28 2002