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

Re: [PATCH] The blame speedup

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-05-31 10:50:37 CEST

On Mon, 31 May 2004, Greg Hudson wrote:

> On Sun, 2004-05-30 at 19:33, Peter N. Lundblad wrote:
> > As you'll notice, this is work in progress. If anyone has time and
> > interest, I'd like to ask for some review. Especially, I'm interested in
> > comments on the client interface. I've settled on letting the RA layer
> > create temporary files for the contents, giving the filename to the client
> > callback. It is guaranteed that the file is available as long as is needed
> > by the blame command. So, I'm not exposing any deltas in the client
> > interface. This is inconsistent with some other interfaces, but it avoids
> > having ra_local compute deltas between all revisions. As I've said
> > earlier, deltas will be used in the network protocols.
>
> Hm. In general, we're much happier with streams than files, at the API

Yes, I no its not like the other interfaces.

> level. The file-rev callback could provide a writable stream to the RA
> function. In "svn blame", that callback would just write out a
> temporary file to be passed to libsvn_diff (using
> svn_stream_from_aprfile).

I've considered this too. But then both the RA layer and the client layer
will write its own version of the temporary file. Networked RA layers need
to keep the fulltext to be able to apply the next text delta. Or, how
would the RA layer get to the file created by the client through the
svn_stream_t?

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 31 10:41:11 2004

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.