On Tue, 2011-08-02 at 16:23 +0200, Bert Huijben wrote:
> 
> > -----Original Message-----
> > From: Julian Foad [mailto:julian.f...@wandisco.com]
> > Sent: dinsdag 2 augustus 2011 15:59
> > To: Subversion Development
> > Subject: RFC: Improving the 'diff callbacks'
> > 
> > I'm looking at rationalizing the way the client handles diffs, which is
> > currently mostly through the "svn_wc_diff_callbacks4_t" interface, with
> > some use made of svn_delta_editor_t.  I'll loosely abbreviate symbol
> > names below, for example "diff_callbacks_t" to refer to the former.
> > 
> > In libsvn_client, currently:
> > 
> >   Diff what?    Producer            Interface           Consumer
> > 
> > Normal diff:
> >   repo-repo  svn_ra_do_diff3 + |> diff_callbacks_t |> diff_callbacks
> >              get_diff_editor   |                   |   in diff.c;
> >   repo-wc    svn_ra + svn_wc   |                   |   prints diff to
> >   wc-wc      svn_wc_diff6      |                   |   stdout
> > 
> > Summarizing diff:
> >   repo-repo  svn_ra_do_diff3   |> delta_editor_t   |> repos_diff_
> >                                |                   |   summarize.c;
> >                                |                   |   calls sum-cb
> >   repo-wc    not implemented
> >   wc-wc      not implemented
> > 
> > What's going on here?  Why is the summarizing diff output subsystem not
> > simply an alternative consumer to the normal diff?  If it used the same
> > interface, we should be able to plug it straight in.
> > 
> > First I wondered why the delta_editor_t isn't a suitable interface for
> > diffs, and why the WC defines its own 'callback' type for this.  One
> > reason is because we want a symmetric diff, one that provides the full
> > content of both what's added and what's deleted.  Although the
> > summarizing diff doesn't need to know about file content or property
> > deletions, it does want to know about file and directory deletions, so
> > that would seem to be a good thing.  So why aren't we using the
> > diff_callbacks_t here?
> 
> Maybe because the diff callbacks transfer the full texts of both
> before and after a change to provide them to the callback?

It appears that the diff_callbacks_t can already avoid that: the
'file_opened' callback says:

/* This function is called before @a file_changed to allow callbacks to
 * skip the most expensive processing of retrieving the file data. */

- Julian

> The summarize function might have been designed to reduce that overhead?


Reply via email to