On Thu, Nov 13, 2008 at 02:25:28PM +0000, Julian Foad wrote:
> On Thu, 2008-11-13 at 09:19 -0500, Mark Phippard wrote:
> > On Thu, Nov 13, 2008 at 9:08 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> > > There are two ways to make an API stable. Use it, test it, and become
> > > comfortable that it is right, or promise that it will be stable from now
> > > on and then do whatever is necessary to support it the way it is, even
> > > if that turns out to be poor and supporting it restricts further
> > > development.
> > >
> > > I don't like the idea of promising to support these, when there don't
> > > seem to be any significant benefits to doing so. Mark agreed.
> > We talked about this a bit at the summit. If we could start over, I
> > do not think the WC library should be public at all. We'd probably
> > have to expose some more things at the client level, but I do not
> > think we did ourselves any favors by making that part of our code a
> > public API. I am sure there are some consumers of this API out in the
> > wild, but I'd be willing to bet the number is very small.
> > Given that we cannot start over, then we have to maintain this API and
> > that also means adding new API for new features. I simply said to
> > Julian that I did not think there was any reason to rush out and start
> > making more of the API public. We know the Tree Conflict feature will
> > need to evolve over the next couple releases as it expands to cover
> > more. I just did not see any reason to declare the API as public in
> > 1.6.
> > This is not about the code being stable or doing what it is supposed
> > to, it is about do we understand this feature enough today that we
> > want to create an API interface we want to support forever. I do not
> > think we are there yet and given that I cannot see who would ever
> > consume this API, I do not see a reason to make it public right now.
> Thanks for clarifying your position, Mark.
A quick grep of our command-line client sources (from oldish r34007)
showed that our command line client is not using tree-conflict-related
functions from libsvn_wc directly. That was what my concern was about,
but turns out it was unfounded.
+1 on making clients access this feature through the client lib
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-13 20:22:38 CET