[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 4621 - in trunk/subversion: include libsvn_client clients/cmdline svnversion

From: <gstein_at_lyra.org>
Date: 2003-01-30 02:48:42 CET

On Wed, Jan 29, 2003 at 08:22:26PM -0500, Garrett Rooney wrote:
 On Wednesday, January 29, 2003, at 07:53 PM, Greg Stein wrote:
 i could go either way on this. keeping it opaque seemed like a
 reasonable idea so that we could easily add new things to it in the
 future (post-1.0) while still remaining binary compatability, but
 realistically, if we're adding new callbacks or something keeping
 binary compatability might be pointless if we're breaking semantic
  Why the whole error thing? Just return NULL. It could be quite a valid
  approach for the caller to want to check if auth stuff has been
  installed or
  not. They shouldn't have to deal with error returns.
 as i start playing with the notification baton, it is getting more and
 more annoying having the error return, since having a null notification
 function/baton is completely valid. i'm definately leaning towards
 forgetting about the error and just returning null if there isn't
 anything set.


  Basically, it seems like there is too much engineering around what
  be a simple structure.
 i'm still not sure if it's worth leaving this opaque or not. is their
 any advantage in being able to change this later while retaining binary

You mention binary compatibility here and above. You may have missed a point
that I made: the context would be opaque *outside* of libsvn_client, but
visible *inside*. You don't have to be binary compat for inside things. If
you make a change to the context, then you're upgrading the library, which
means that you're also updating all uses of the non-opaque structure.


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:24:53 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.