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

Re: [PATCH] Better progress indicator for the 'svn' command-line client

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-07-09 15:52:21 CEST

Mukund <mukund@tessna.com> writes:

> On Wed, Jul 09, 2003 at 02:26:27PM +0100, Philip Martin wrote:
> | Suppose my application makes several Subversion API calls in
> | succesion. Am I allowed to reuse the feedback baton? When should I
> | reset the state in the baton? How does the reset interact with the
> | the cancel func? Does your choice of API mean that I am unable to
> | reuse a baton? Is that a bikeshed?
>
> I am unable to follow what you are saying, maybe due to my lack of
> knowledge of Subversion.

I was asking if I can reuse a baton

    svn_client_ctx_t ctx;
    ctx.notify_func = foo;
    ctx.notify_baton = bar;
    svn_client_update(... &ctx, ...);
    svn_client_commit(... &ctx, ...);
    svn_client_update(... &ctx, ...);

> The only field in the baton which the
> patch touches is a newly added one -- a counter. The counter is reset
> every time during the first TX, i.e., when sent_first_txdelta in the
> baton is FALSE.

Well that covers this particular callback/baton. What if I write
another application? Your choice of API will affect the way I can use
the callback/baton.

Philip goes and reads the patch...

I see we already have some state in the feedback baton. If the API
passed two numbers then sent_first_txdelta could be removed from the
baton. The received_some_change state would have to remain, but that
is a slightly different category since it does not affect the
callback's output.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 9 15:53:20 2003

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.