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 EligableForMerge implements LogMessageCallback
> {
> public EligableForMerge(String mergeTarget);
> }
>
> What do you think?
I do not completely understand, probably because I am not aware of the
details of the C implementation you are referring to. 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?
In Subclipse I wrote a LogMessageCallback that handles the nested
revisions when the -g option is used. How would this mix with that?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 9 04:18:16 2007