On 5/23/06, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> > > +svn_error_t *
> > > +svn_client_retrieve_changelist(apr_array_header_t **paths,
> > > + const char *changelist_name,
> > > + const char *root_path,
> > > + svn_cancel_func_t cancel_func,
> > > + void *cancel_baton,
> > > + apr_pool_t *pool);
> > > +
> >
> > In the past we've had to go from functions like this that gather up
> > all their return values and pass them back in an array to streamy
> > interfaces that use a callback/baton pair. Would it make sense to
> > just start this with the streamy version? I mean you can build the
> > current interface on top of a callback driven version, but not the
> > other way around...
>
> What's would be the motivation to make this API streamy? It can't be
> a matter of 'perceived user response time' (a la 'svn status'),
> because we're just gathering targets to feed to the subcommand,
> there's nothing to print. Is it a matter of trying to bound memory
> usage? I don't think that's relevant here either, since every
> subcommand always holds the whole array of targets in memory anyway
> (which we're just augmenting with some crawl results).
Well, that's assuming that this function is only ever used to pass the
set of paths in the changelist off to some other task. I could
envision someone using it to implement "show me what files are part of
this changelist", in which case you could just print them out
directly.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 23 20:59:38 2006