> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: dinsdag 28 januari 2014 12:12
> To: Bert Huijben
> Cc: Branko Èibej; dev_at_subversion.apache.org
> Subject: Re: 1.9 issues
>
> On Fri, Jan 24, 2014 at 3:17 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
> >...
> > And in many discussions the result is that we should have never
introduced
> > libsvn_wc and libsvn_client as separate libraries.
>
> Could we take every function in svn_wc_private.h and move them into
> libsvn_client? (I'm assuming those functions are *only* called from
> _client) ... certainly, we may need some new entrypoints to support
> the shifted functions, but how much can be shifted over?
>
> Is it possible to say "no more WC functions" and only introduce
> public/private Client functions? (and hide the very low-level piping
> in svn_wc_private)
>
> In short: how much could be migrated to eliminate the client/wc
distinction?
>
> (I disagree with folding in RA, however)
>
> > I don't see a problem with adding yet another library, but I don't like
>
> Ugh. We have too many already.
>
> >...
> > +1 on moving it to another header file, but I'm not sure about the
> > requirement for yet another library... especially with a name that tells
the
> > user nothing... Every library is a 'tool'.
>
> Agreed.
>
> And how solid are these? Should they hang in include/private for one
> release?
>
> I look at mtcc.h and the header is *broken*. The #define guard is
> wrong, there is no extern "C" in there. It seems immature, and not
> ready for immediate release.
mtcc.h is a library internal header. The public api is currently in
svn_client.h. That is what all the discussion is about.
So thanks for directly jumping to a conclusion based on a subset of the
information; and without looking at the actual code.
[If you don't see an import of mtcc.h in mtcc-test.c and in svmucc.c,
perhaps that should tell you that you don't look at the right header, or
even the right api...]
Bert
Received on 2014-01-28 13:03:00 CET