You're one offering plate short of being a great preacher. +1 on
allll of this.
Ben Collins-Sussman <sussman@collab.net> writes:
> 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
---------------------------------------------------------------------
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:54:31 2004