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

Re: ra_dav wackies

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-06-27 21:24:58 CEST

On Wed, Jun 27, 2001 at 11:47:54AM +0100, Joe Orton wrote:
> On Wed, Jun 27, 2001 at 03:42:11AM -0700, Greg Stein wrote:
> ...
> > Okay... that file is for the "report" that we send to the server. I think
> > there was going to be an API for writing bits, rather than the whole thing.
> > I don't remember and will need to look at the Neon API again. I also had
> > some changes in mind for Neon that I volunteered for a couple months ago(!)
> > but Joe may have already done them. Anyway... I believe we may be able to
> > toss the file. If not, we may want to look at using SVN/tmp/ to hold it.
> I looked at this and I wasn't quite sure why the REPORT body had to be
> buffered to a file, it looked like it was just going to contain a few
> lines of XML. Could it be buffered in memory instead? (I can patch that
> if so)

The report body is arbitrary size. It depends on the number of differences
in versions you have in your WC. If you have a large WC with a large
variation in versions, then the report is going to be quite large.

> If not, it will be pretty difficult to re-do neon to allow
> caller-pushing request bodies through. (neon can do neon-pulls request
> body and caller-pulls response body now though.)

Okay, no problem. We can continue to buffer. As I mentioned in a comment in
that code, we can also spin up a thread and use a pipe between the
client-push and the neon-pull. (if we really dislike the buffering for some
reason; my tendency is to avoid the thread)


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 Sat Oct 21 14:36:32 2006

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.