On Thu, Apr 8, 2010 at 10:02 PM, Greg Stein <gst...@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
