> -----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? The summarize function might have been designed to reduce that overhead? Bert