I’m not sure if I can call this ‘mtcc library’ / ‘mtcc feature set’ a layering violation.
It uses both libsvn_client and libsvn_wc in its implementation, which no
other existing libraries currently uses.
And in many discussions the result is that we should have never introduced
libsvn_wc and libsvn_client as separate libraries. (If we hadn’t split those
up it would be far easier to change the pristine requirements. We currently
can’t contact the repository from libsvn_wc, so there is no way we can call
into the ra layers from there without revving +- every api.)
I don’t see a problem with adding yet another library, but I don’t like
that we move to adding more and more private functions for communicating
between libraries. Many of these functions (especially those in libsvn_wc
and libsvn_client) would be interesting for other library users to use.
Making the mtcc api experimental would in my eyes require moving ‘svnmucc’
back to experimental too (except for the reason that this would be
impossible without a time machine).
+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’.
‘svn_tool.h’
No, I don’t like that name either as it wouldn’t add anything above just
‘svn.h’.
And I don’t think the mtcc api is big enough to call it svn_mtcc.h. (And I
don’t expect much growth of the api in future versions). Suggestions?
Bert
From: Branko Čibej [mailto:br...@wandisco.com]
Sent: vrijdag 24 januari 2014 21:29
To: dev@subversion.apache.org
Subject: Re: 1.9 issues
On 24.01.2014 18:20, Ben Reser wrote:
2) libsvn_client_mtcc_*: Should these exist at all or be moved to another
library? This conversation died out.
I asked for this API to be marked experimental, and was ignored. I'm not at
all happy about that.
I'm going to take this opportunity to say -1 to having this in
libsvn_client. It's a layering violation. Instead, I propose we introduce a
new API module and library, svn_tools, that contains all the various APIfied
functionality from our command-line utilities (apart from the svn client
itself, of course). The MTCC API should be moved to svn_tools. If we have
APIs for svnversion, svnadmin, etc., that are not already covered by the
existing librararies, we should move them, too.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com <mailto:br...@wandisco.com>
<<attachment: winmail.dat>>
