On Thu, Apr 8, 2010 at 10:02 PM, Greg Stein <gstein_at_gmail.com> wrote:
> Hey all,
>
> It has come up a few times on IRC discussions: "we should never have
> exposed libsvn_wc, just libsvn_client".
>
> Well, we've already exposed it, so we need to at least keep that stuff
> around. But moving forward... should new functions continue to be
> exposed? Or should all new functions go into svn_wc_private.h?
>
> This question is (probably) directed at our (GUI) client developers.
> Do you ever use WC functions? And if you do, then which ones? Where is
> svn_client.h insufficient, leading you to use svn_wc.h APIs?
>
> Note: I think the separation is a Good Thing, for our benefit, but we
> don't necessarily have to expose the WC layer to downstream
> developers.
>
I am not a GUI client developer.
That being said: I don't think we should deprecate svn_wc.h until 2.0.
Don't get me wrong: I would like to dump all that stuff and not have to
worry about holding on to backward compat for new wc APIs going forward.
I'm just concerned that junking stuff now would result in mass confusion
when rev'ing stuff in svn_wc.h. For instance, all the notification types
are defined as svn_wc_notify_*. If we deprecate svn_wc.h, what happens when
we need to add another notification type in 1.8? It seems like a lot of
work for whoever that unfortunate soul happens to be.
You rightly point out that things are a mess in the interface between
libsvn_client and libsvn_wc right now. To really fix the problem, we need
to examine the interfaces, and move stuff there it more appropriately
belongs (e.g., notification should be it's own subsystem, *not* part of
libsvn_wc). Whenever 2.0 happens, it will give us the chance to do that,
but fulling deprecating svn_wc.h right now is just a band-aid over a much
deeper problem, and will make things even worse.
-Hyrum
Received on 2010-04-09 22:18:46 CEST