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

Re: [PATCH] svn_client_ctx_t (was Re: Issue #1004 and Garrett Rooney)

From: <kfogel_at_newton.ch.collab.net>
Date: 2003-01-25 06:15:29 CET

Garrett Rooney rooneg@electricjellyfish.net writes:
 ok, here's my current take on the svn_client_ctx_t issue.
 there's a /ton/ of stuff that we'd like to move in to this structure,
 and doing it all at once is madness, so i'm going to take an
 incremental approach, starting one at a time at the top level of the
 API (the functions in svn_client.h), and as i move more and more parts
 of the client specific data in to the context object, i'll push the
 context object further into the guts of libsvn_client and libsvn_wc.

That's the strategy I was thinking too, cool.

I don't think the client_ctx_t baton itself would ever get passed down
into libsvn_wc; but some of the things *in* the baton might be passed
as individual arguments to libsvn_wc functions, of course.

 the first thing i thought would be nice to move was the
 svn_client_auth_baton_t's that get passed to everything that accesses
 the repository directly. i've got a first cut at that done, just
 doing so for svn_client_checkout (and the functions were affected by
 that change, progressing only far enough to make things build and pass
 make check).
 assuming people like this approach, i was going to finish up moving
 the auth batons in, then get the patch to the point where it can be
 committed, commit it, then move on to the notification functions, and
 probably config options after that (since that requires the context
 object to be passed much further down the chain).
 after all this is done, then i'll start looking at doing the
 cancelation stuff, which is the whole point of this exercise, if you
 remember the issue at hand ;-)

Is there any reason not to start with the cancellation stuff, and then
do the other stuff? It all has to get done, sure, but at least that
way we'd grow the new feature earlier :-).

Your call, just pointing out the possibility.

(I haven't looked at the patch itself in detail yet, just due to
scheduling, but will.)

Thanks, Garrett,

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:16:42 2006

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.