On Thu, 14 Dec 2006, Mark Phippard wrote:
...
> >On Thu, 07 Dec 2006, Daniel Rall wrote:
> >...
> >> Mark, could you take a look at the DiffSummaryReceiver and
> >> DiffSummary APIs, and make sure they're in usable shape? I'm
> >> especially interested if you think we should pull the
> >> DiffSummary.DiffKind class out and make it more like the other
> >> classes which correspond to C enums which are found in JavaHL.
...
> 1) Should the diffSummarize method take pegRevision arguments?
Yes, we should also support svn_client.h's svn_client_diff_summarize_peg()
API.
> 2) Should DiffSummary have a textChanged boolean that corresponds to the
> propsChanged boolean? Obviously if an item is modified, and propsChanged is
> false, then you know the text has changed. But if propsChanged is true, you
> have no way to know whether the text was also changed. It is conceivable
> that someone doing a graphical diff tool would only care about file changes
> and not prop changes.
The way the C API handles the "prop changes and possible text changes"
case is via the svn_client_diff_summarize_t's summarize_kind field,
which is set to svn_client_diff_summarize_kind_normal (documented to
describe an "item with no text modifications"), or another value. The
JavaHL API currently provides access to this value through the
DiffSummary.getDiffKind() API.
Do you think we should represent this differently in the JavaHL API,
or simply document things better?
- Dan
p.s. Merge Tracking questions to be answered in a separate email.
- application/pgp-signature attachment: stored
Received on Tue Dec 19 02:02:05 2006