> -----Original Message-----
> From: Julian Foad [mailto:julian.foad_at_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.foad_at_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
Received on 2011-08-02 17:09:44 CEST