> -----Original Message-----
> From: Julian Foad [mailto:julian.f...@wandisco.com]
> Sent: dinsdag 2 augustus 2011 16:57
> To: Bert Huijben
> Cc: 'Subversion Development'
> Subject: RE: Improving the 'diff callbacks'
>
> 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. */
If you do that (returning skip status) you don't get the information on text
and property changes.
How would you generate the summary without those callbacks being invoked?
Bert
