On Fri, 08 Jun 2007, Mark Phippard wrote:
> On 6/8/07, Daniel Rall <dlr@collab.net> wrote:
> >> Let me describe what I think I would like in Subclipse and JavaHL.
> >...
> >> void logMessages(String url, Revision pegRevision,
> >> Revision revisionStart,
> >> Revision revisionEnd, boolean stopOnCopy,
> >> boolean discoverPath, boolean includeMergedRevisions,
> >> long limit, LogMessageCallback callback,
> >> boolean showEligibleOnly, String mergeTarget)
> >>
> >> Basically, it adds a boolean that says to only show the eligible
> >> revisions, and a String to give the local path you are merging into.
> >> Internally, the API would use the mergeinfo property to filter the
> >> values returned from the API to only include revisions eligible to be
> >> merged.
> >
> >In the C API, I could see this being implemented via a
> >svn_log_message_receiver2_t which filtered out revisions from the
> >merge info.
> >
> >We could provide a similar LogMessageCallback without changing the
> >void logMessages(...) signature. Something like:
> >
public class EligableForMerge implements LogMessageCallback
> >{
public EligableForMerge(String mergeTarget) { ... }
> >}
...
>
> I do not completely understand, probably because I am not aware of the
> details of the C implementation you are referring to.
All I meant is that the C APIs that could be used to implement this
feature on the client side are very similar to the Java APIs
(e.g. svn_log_message_receiver2_t corresponds directly to
LogMessageCallback).
> It sounds like you are saying rather than need a new signature, we
> could provide an implementation of the callback that does the
> filtering? I guess that means it all has to be done on the client
> side?
Yes -- using this style of implementation would indeed handle it all
on the client-side. This would allow us to roll out this
functionality without adding new, special-purpose code to the RA and
repository layers.
Doing this filtering on the repository-side would certainly be more
efficient, in that the RA layer could avoid marshalling the log data
back to the client, and the client could avoid having to filter those
logs.
> In Subclipse I wrote a LogMessageCallback that handles the nested
> revisions when the -g option is used. How would this mix with that?
Wrapping the suggested JavaHL callback would work. This could be done
by altering the Subclipse implementation's contructor to take one or
more LogMessageCallbacks to delegate to when the callback is invoked,
and pass EligableForMerge in there.
- application/pgp-signature attachment: stored
Received on Mon Jun 11 10:22:36 2007