On Wed, 26 May 2004, Mark Benedetto King wrote:
> On Wed, May 26, 2004 at 09:29:43AM +0200, Peter N. Lundblad wrote:
> > On Wed, 26 May 2004, Greg Hudson wrote:
> > Another approach that springs to my mind is not to expose the deltas in
> > the RA interface, so we would move my previous typedef to svn_repos
> > (renaming it) and in svn_ra.h add
> > typedef svn_error_t *(*svn_ra_file_rev_handler_t)
> > (void *baton,
> > const char *path,
> > svn_revnum_t revnum,
> > apr_hash_t *rev_props,
> > svn_stream_t **contents,
> > apr_hash_t *props,
> > apr_pool_t *pool);
> > Then it could be implemented using the repository function for network RA
> > implementations, but for ra_local, we don't need to calculate the deltas.
> > I don't know if this is faster, but in any case, the client only cares
> > about the whole file, so why give it a delta?
> If we're going through all the trouble of building a more efficient
> blame interface, we might as go all the way and:
> 1.) save the server from the hassle of re-combining all the deltas
> to compute the fulltext of every rev.
Today, it has to recreate each fulltext, but does it have to do that in my
proposed svn_repos interface (not that above, but in an earlier post),
where we ask for deltas for each revision in increasing order? I'm not
familira with the FS internals, so I don't know. Could you explain your
above comment in more concrete terms? :-)
> 2.) eventually give the client an opportunity to do something
> sneaky w.r.t. deltas + svn_diff(). If we always send fulltexts,
> the change information is lost and must be recomputed.
As you see above, I propose to send deltas over the wire. That was the
original motivation for me to start this. My question here
was about libsvn_ra. Should the RA implementation (on the client side)
reconstruct the fulltext, or will it be useful for libsvn_client to have
the delta instead?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed May 26 19:04:34 2004