On 12/13/06, Daniel Rall <email@example.com> 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.
> Ping. Not urgent, just don't want to forget about it before the API
> ships and is frozen...
I had forgotten, thanks.
I think the shape of the API's is OK. These are the comments I would make:
1) Should the diffSummarize method take pegRevision arguments?
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.
On a related note, when the merge tracking stuff is brought to trunk, will
their be JavaHL related changes to make? I assume there will be some new
methods and/or new method signatures? I have not looked into what is
happening on that branch too closely.
Received on Thu Dec 14 16:17:08 2006