On Jul 25, 2007, at 12:26 PM, David Glasser wrote:
> On 7/25/07, Daniel Rall <dlr@finemaltcoding.com> wrote:
>>
>> On Jul 25, 2007, at 9:53 AM, C. Michael Pilato wrote:
>> > 3. don't rev svn_repos_history(), and use callback cancellation
>> > exclusively to control continuation of the function.
>>
>> I like option #3, , along with an svn_cancel_func_t implementation
>> which treats its baton as a limit and count parameter.
>
> +1
Turns out Mike was really talking about having ANY callback be able
to return an error code (a la SVN_ERR_CANCELLED) signifying that the
callback should not be invoked again. Invokers of the callback would
catch this error, clear it, and return SVN_NO_ERROR.
David pointed out that while this works for most cases, that
sometimes you want to invoke a cancellation callback more often than
you would a function callback.
>> Perhaps
>> something like:
>>
>> /** An implementation of the svn_cancel_func_t API which takes @c
>> apr_size_t[2] of @c {limit,count} for its @a baton parameter. */
>> svn_error_t *
>> svn_repos_history_limit(void *baton)
>> {
>> apr_size_t *limit_and_count = baton;
>> apr_size_t limit = limit_and_count[0];
>> apr_size_t count = limit_and_count[1];
>> if (limit < 1)
>> return;
>> count++;
>
> This isn't actually incrementing the element in the baton.
>
>> if (count >= limit)
>> return SVN_ERR_CANCELLED;
>> return SVN_NO_ERROR;
>> }
>>
>> Untested patch with the API change attached.
>
> Looks good (also untested), though there's a spurious "count" variable
> in svn_repos_history3, and I would make its docstring say "invoke it
> after each revision", not "at various times".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 25 22:57:56 2007