On Jul 25, 2007, at 9:53 AM, C. Michael Pilato wrote:
> Jens Peters wrote:
>>> Seems useful in general, though! Even if you do go with Mike's
>>> suggestion to make the callback say whether or not it should
>>> continue,
>>> a "limit" argument is often helpful (I think SVK would use it),
>>> and so
>>> if you go down Mike's path adding a function which takes a log
>>> callback and a limit integer and returns a new log callback which
>>> does
>>> the limit logic for you would be nice.
>
> I see the following courses of action here as options:
>
> 1. rev svn_repos_history() to add a 'limit' parameter and uses it
> exclusively to control continuation of the function.
>
> 2. rev svn_repos_history() to add a 'limit' parameter and uses it
> in concert with callback cancellation to control continuation of
> the function.
>
> 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. 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++;
if (count >= limit)
return SVN_ERR_CANCELLED;
return SVN_NO_ERROR;
}
Untested patch with the API change attached.
---------------------------------------------------------------------
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 Wed Jul 25 20:42:09 2007