[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] add limit argument to svn_repos_history

From: Daniel Rall <dlr_at_finemaltcoding.com>
Date: 2007-07-26 10:20:31 CEST

On Jul 25, 2007, at 7:41 PM, C. Michael Pilato wrote:

> Daniel Rall wrote:
>>
>> 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.
>
> Right. Which is why I was *not* also advocating removing
> cancel_funcs from
> functions that take them. I'm talking about supporting the likes
> of this:

So, nor are you in favor of adding them to functions which don't take
them?

I'm attaching a patch implementing your suggestion for
svn_repos_history2(), along with a new 'svnlook history --limit'
option. Note that this doesn't rev the underlying API, but does
change its behavior WRT the SVN_ERR_CANCELLED error code.

- Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

  • application/octet-stream attachment: patch
Received on Thu Jul 26 10:13:35 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.