Re: svn commit: rev 4824 - in trunk/subversion: svnadmin include libsvn_subr svnlook clients clients/cmdline tests/libsvn_subr svnserve svnversion

On Tue, 2003-02-11 at 13:11, Branko Èibej wrote:
> As you might have guessed, given the last paragraph above, I don't agree
> with putting this into libsvn_subr. It doesn't belong there. We need a
> separate library that contains only utilities for our command-line
> clients. There are other things that should go there; for instance,
> svn_path_internal_style and svn_path_local_style don't belong in
> libsvn_subr, nor does opt.c.

It would be neat to have a library which wraps libsvn_client and:

  * Accepts strings in the native charset
  * Accepts non-canonicalized paths
  * Doesn't use pool arguments (it would use a context, and would use a
    subpool per operation, which is okay because the libsvn_client
    operations are large-grain)
  * Can contain initialization functions like this one

In general, we would be aiming for the simplest possible interface for
applications. My only concern is that applications would eventually
need to probe into the regular libraries like libsvn_wc, and now they
need pools and charset conversion and path canonicalization again (and
only for those calls, which is confusing).

> I also strongly suspect that the command-line client support library
> should _only_ exist as a static lib, not a shared one.

Why? (As an argument against, I believe Debian has a policy against
static-only libraries of any sort, though I've never determined why.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 11 20:59:38 2003