On Wed, May 26, 2004 at 09:29:43AM +0200, Peter N. Lundblad wrote:
> On Wed, 26 May 2004, Greg Hudson wrote:
>
> > On Tue, 2004-05-25 at 16:44, Peter N. Lundblad wrote:
> > > Not really. As you can see below, I need svn_txdelta_window_handler_t,
> > > which is in svn_delta.h, which include svn_types. Hmmm...
> >
> > Another option is to use an iterative iterface (a la svn_fs_history)
> > rather than a callback interface in libsvn_repos. Then only svn_ra
> > needs the callback type. Contrived? Possibly. But an iterative
> > interface is often easier to use than a callback interface anyway, so it
> > makes some sense to provide one when we can. And there's precedent for
> > do_log vs. svn_fs_history.
> >
> Yes, that would be possible.
>
> 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.
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.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 26 18:09:47 2004