Greg Hudson <ghudson@MIT.EDU> writes:
> Going back to the original question, though, I'm worried about the
> amount of garbage going into the libsvn_client interface. This is a
> very granular interface; performance-wise, no one is likely to notice if
> we allocate a pool, parse a configuration file, and maybe factor a few
> smallish composite numbers each time a call is made to a libsvn_client
> function. However, we ask the caller to canonicalize paths, convert any
> string data to UTF-8, pass in a valid pool, and now maybe pass in a
> valid context as well. That may be good for the libsvn_wc interface,
> which is fine-grained (yes?) and used by other libraries, but for
> libsvn_client we might want to adopt a more caller-friendly convention.
Hmmmm. Yeah, but I think the issue here is that we'll now depend on
the config for every conversion of apr_timet_t to human-readable
string. These conversions don't just happen at the initial call into
libsvn_client; they might happen any time, really.
Nuutti, perhaps a way to start on solving this is to first see where
we do such conversions, and try to delay them until we get out to the
original caller (the command line client itself, for example).
There's no real reason libsvn_wc has to convert dates to strings in a
way that conforms with the user's configuration, is there? I wasn't
thinking this would apply to keyword expansion, only to printing out
dates and accepting them as input -- both of which are functions of
the client layer nearest the user. So perhaps we should just have a
separate date conversion function that reads the config (yes,
expensive) and converts accordingly, and only the client code would
use it.
Thoughts?,
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 14 18:50:26 2002