[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Improving the 'diff callbacks'

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Tue, 02 Aug 2011 15:56:46 +0100

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. */

- Julian

> The summarize function might have been designed to reduce that overhead?
Received on 2011-08-02 16:57:22 CEST

This is an archived mail posted to the Subversion Dev mailing list.