Why do we allowed mixed versions of libsvn_* ?

I'm getting annoyed by our version compatibility checks.

libsvn_fs has a private vtable, and libsvn_fs_base and libsvn_fs_fs
implement the vtable. I'd like to change the the vtable definition and
both implementations in one swoop. I don't want to be forced into
adding new functions, incrementing the name of the vtable, or other
such things.

But I can't do that. Apparently it's possible for libsvn_fs 1.1 to
load libsvn_fs_base 1.2... which would then blow up. Our version
checks allow this.

Why on earth do we allow different versions svn libraries to mix and
match with each other?

    - I completely understand the need for forward compatibility with
*applications*. A 1.0 application should be able to link to any 'set'
of svn libraries greater than 1.0.

    - I completely understand the need for a 1.X client and 1.Y server
to interoperate, for any values of X and Y.

    - I do *not* understand why we need to worry about libsvn_foo 1.X
interoperating with libsvn_bar 1.Y, for random values of X and Y. Why
aren't we just treating {libsvn_*} as single unit? Do we actually
expect users to have a hodgepodge of libsvn_* libraries? Why allow it
at all? As far as I can tell, this requirement is needlessly
inhibiting our ability to develop new features, with no real benefit to
users. It makes our lives complicated and causes headaches.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 3 20:46:08 2004