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

Re: svn commit: r9664 - in trunk/subversion: clients/cmdline include libsvn_client libsvn_subr

From: Branko ╚ibej <brane_at_xbc.nu>
Date: 2004-05-10 21:00:25 CEST

Greg Hudson wrote:

>On Mon, 2004-05-10 at 02:53, Branko ╚ibej wrote:
>>I committed a prototype implementation of version query functions.
>>Please look at it, and if it's acceptable, I'll implement the rest of
>>the functions and add version queries to all the command-line tools.
>Uh, -1, unless I missed some design discussion on this.
The preliminary discussion happened mostly on IRC, I think, but I recall
some requests to users@ about getting the library version at runtime,
and also a comment in svn_version.h about that. Anyway, my commit was
intended to start this discussion. Since the commit is fairly small, I
thought it would be easier to start with working code and take it from
there. :-)

>Adding a new
>utility function here and there is fine, in my opinion, but adding a new
>subsystem should really not happen without prior discussion.
"Review after commit," and the old-boy network and stuff. :-)

>I am +0 on adding functions to query a library's version.

>I am -0 on
>adding machinery to check library version mismatches at runtime, because
>I don't see a lot of potential for accidental mismatches and because I
>haven't seen much of that machinery in other projects.
    * Lots of users have been burned by this, and got obscure error
      messages instead of what they'de get with this scheme.
    * We check the BDB version at runtime.
    * We check RA and FS(A)P versions at runtime.

>Specific comments on the implementation:
>+#define SVN_VER_GEN_PROTO(name) \
>+#define SVN_VER_GEN_IMPL(name) \
>+#define SVN_VER_COMPATIBLE(name) \
>I do not believe we should be using the preprocessor to this extent.
>The preprocessor is not our friend. Suppose I run into a problem
>involving svn_subr_version and I want to find out where it's defined? I
>can't grep for it, because it was defined with SVN_VER_GEN_IMPL(subr).
I agree this could be a problem, even though GCC at least will point to
the macro definition, and GDB will single-step through it. On the other
hand, the svn_*_version functions are so simple that I'm prepared to
formally prove their correctness, and I decided on the macro approach
because we're going to have many of them, and definitely want them all
to be the same.

I'd be prepared to reconsider if problems show up in SWIG and/or Doxygen.

>+svn_boolean_t svn_ver_compatible (const svn_version_t *versioninfo,
>+svn_boolean_t svn_ver_callback_compatible (const svn_version_t *versioninfo,
>The asymmetry between the two version arguments (one specified as a
>structure pointer, the other split out into four parameters) seems
Yes, it does. It's there because I didn't see any other way to generate
the shorthand macros. I do see a better way now, and will change those

>What's the definition of "callback compatibility?" The implementation
>seems to simply reverse the direction of the compatibility test. To the
>best of my knowledge, we treat changing the signature of a callback as
>if it were changing the signature of any API which uses that callback,
>so we have no concept of "callback compatibility."
This is one of the things I wanted to discuss, as it hinges on the
interpretation of our versioning rules. We have a number of callback
functions that the user of a library has to register in many batons. If
our versioning guarantees cover such callbacks in the same "direction"
as ordinary calls, then the callback-compatibility check can go away --
I'd like to see that happen, too. But I need a second opinion regarding
the interpretation of the versioning guarantees.

>Compatibility is directional, but the docstring for svn_ver_compatible
>does not say which direction it checks compatibility in.
Hm? Yes it does; "for calls into the library", and callback
compatibility is "for callbacks from the library", that is, in the other

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 10 21:01:11 2004

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.