Garrett Rooney firstname.lastname@example.org 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
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.)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 14 02:16:42 2006