On 02/17/2011 08:19 AM, Hyrum K Wright wrote:
> Without having looked at that code recently, I think this is the right
> strategy. If the APIs are useful outside of Subversion, let's expose
> 'em publicly, instead of making those consumers feel like second-class
> Last summer in Berlin we had a quite heated discussion about just
> deprecating all of libsvn_wc APIs. I was against such a move (at
> least until 2.0) in that it would leave the existing APIs public, but
> any new ones private, and the whole interface in limbo. I still feel
> that way, and this discussion vindicates that feeling (at least to me
> :) ).
Perhaps you need to stop thinking of TortoiseSVN as "outside of Subversion".
We should be able to provide useful, public *libsvn_client* APIs that
aren't solely consumed -- or consumed at all -- by the command-line client.
libsvn_client wasn't designed to be used only by 'svn'.
I concede that this mass deprecation would leave the svn_wc interface in
limbo. But I also don't care, because I would bet dimes to dollars that
*nobody* is using that API for something other than Subversion version
control. Therefore, it's perfectly okay in my book to deprecate a svn_wc
function with a pointer to its replacement in svn_client.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-02-17 15:31:13 CET