> -----Original Message----- > From: Greg Stein [mailto:gst...@gmail.com] > Sent: dinsdag 28 januari 2014 12:12 > To: Bert Huijben > Cc: Branko Čibej; dev@subversion.apache.org > Subject: Re: 1.9 issues > > On Fri, Jan 24, 2014 at 3:17 PM, Bert Huijben <b...@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