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

Re: Alpha issues [or "How to Organize Your Weekend" :-) ]

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-07-11 22:32:46 CEST

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)


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

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.