You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/12/03 19:43:31 UTC
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
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by John Peacock <jp...@rowman.com>.
C. Michael Pilato wrote:
> You're one offering plate short of being a great preacher. +1 on
> allll of this.
You're preaching to the choir! I'd vote +3 if I could.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Saturday, December 4, 2004 10:15 AM -0500 Greg Hudson <gh...@MIT.EDU>
wrote:
> I disagree that we have ever promised that we allow mixing of Subversion
> component versions. We've certainly made it break, by using internal
> function names between components. Practically, this has only caused a
> problem when people upgraded all of Subversion without upgrading
> mod_dav_svn.so, which is generally an accident resulting from binary
> packages not taking care of the module upgrade.
Correct. The versioning rules only apply to external applications and
libraries. The Subversion code itself should always assume (and check!) that
the major and minor and patch (?) are equivalent to what it expects. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-12-04 at 09:44, Branko Čibej wrote:
> As long as we state that plainly in our compatibility guarantees; i.e.,
> that different rules apply for client-to-lib compatibility than
> lib-to-lib.
The issue is not client-to-lib versus lib-to-lib. A third-party library
accessing Subversion needs to be able to take advantage of our
compatibility rules, while our own client does not. The issue is
whether it's allowed to mix versions of Subversion components.
> Of course, basically we cheat if we change our compatibility
> rules between minor releases. :-)
I disagree that we have ever promised that we allow mixing of Subversion
component versions. We've certainly made it break, by using internal
function names between components. Practically, this has only caused a
problem when people upgraded all of Subversion without upgrading
mod_dav_svn.so, which is generally an accident resulting from binary
packages not taking care of the module upgrade.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> 1. I'm not going to worry about fs 1.1 trying to load fs_base 1.2.
> If somebody tries that and complains, our response is "don't mix
> library versions".
O.K.
> 2. IMO, all of the version-compatibility funcs that currently exist
> shouldn't be ripped out, they should be used to *enforce* equal
> library versions. I think we should call svn_ver_equal() absolutely
> everywhere we can. :-)
As long as we state that plainly in our compatibility guarantees; i.e.,
that different rules apply for client-to-lib compatibility than
lib-to-lib. Of course, basically we cheat if we change our compatibility
rules between minor releases. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 4, 2004, at 5:15 AM, Branko Čibej wrote:
>
> But first, you'd better explain what's so horribly wrong with the
> exieting FS vtable that you have to completely rewrite it.
I don't have to completely rewrite it. I want to change the signature
of one function in the private FS vtable: begin_txn(). Specifically,
I want to add a 'flags' field, and then I want the two back-ends to
implement the new vtable func signature.
Nothing complicated here. But now I have to worry about libsvn_fs 1.1
possibly loading libsvn_fs_base 1.2 and blowing up, because our
'version checks' allow this to happen.
I see that you committed a stricter version check in libsvn_fs 1.2;
that it now refuses to load anything but a 1.2 fs back-end. I guess
that solves the problem ghudson mentioned (programmatically preventing
the mixing of library versions.)
But in general, I agree with ghudson: we've never promised users that
they can randomly mix versions of libraries. I don't want to make that
promise.
So,
1. I'm not going to worry about fs 1.1 trying to load fs_base 1.2.
If somebody tries that and complains, our response is "don't mix
library versions".
2. IMO, all of the version-compatibility funcs that currently exist
shouldn't be ripped out, they should be used to *enforce* equal library
versions. I think we should call svn_ver_equal() absolutely everywhere
we can. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by Branko Čibej <br...@xbc.nu>.
Whups, I must apologise for being a bit too quick off the mark. I see
the fs module init function is already private. However it's still a bad
idea to throw out the compatibilty check completely, we can just make it
a bit stricter. As I'm about to demonstrate. Feel free to back out my
next commit if you don't like it.
Branko Čibej wrote:
> Ben Collins-Sussman wrote:
>
>>
>> On Dec 3, 2004, at 1:50 PM, C. Michael Pilato wrote:
>>
>>> You're one offering plate short of being a great preacher. +1 on
>>> allll of this.
>>>
>>
>> Well, I haven't got a proposal to rip out compatibility checks
>> (yet). I'd like to give proponents of the system a chance to defend
>> it first.
>
>
> We have strict API (and ABI) compatibility rulesThe version checking
> code simply ensures that we follow them. Nobody objected when I added
> those checks to the FS loader, and whatever others say, one of the
> arguments for having an FS loader in the first place was to let people
> write their own FS modules. Therefore that interface is public.
>
> If you want to take the version checks out, fine, but then you'll have
> to make the interfaces private, and that includes double underscores
> in the function and variable names. And if you do that, you'll be
> violating our compatibility guarantees, which IMHO we should stick to
> as long as we have them. Or we can throw those out too, and remove a
> bunch of versioned functions, which will make our code much cleaner.
>
> But first, you'd better explain what's so horribly wrong with the
> exieting FS vtable that you have to completely rewrite it. I've
> noticed before that a bit of imagination usually make many an
> "inevitable" thing not so inevitable, so share these little design
> issues with us first, please.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>
> On Dec 3, 2004, at 1:50 PM, C. Michael Pilato wrote:
>
>> You're one offering plate short of being a great preacher. +1 on
>> allll of this.
>>
>
> Well, I haven't got a proposal to rip out compatibility checks (yet).
> I'd like to give proponents of the system a chance to defend it first.
We have strict API (and ABI) compatibility rulesThe version checking
code simply ensures that we follow them. Nobody objected when I added
those checks to the FS loader, and whatever others say, one of the
arguments for having an FS loader in the first place was to let people
write their own FS modules. Therefore that interface is public.
If you want to take the version checks out, fine, but then you'll have
to make the interfaces private, and that includes double underscores in
the function and variable names. And if you do that, you'll be violating
our compatibility guarantees, which IMHO we should stick to as long as
we have them. Or we can throw those out too, and remove a bunch of
versioned functions, which will make our code much cleaner.
But first, you'd better explain what's so horribly wrong with the
exieting FS vtable that you have to completely rewrite it. I've noticed
before that a bit of imagination usually make many an "inevitable" thing
not so inevitable, so share these little design issues with us first,
please.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 3, 2004, at 1:50 PM, C. Michael Pilato wrote:
> You're one offering plate short of being a great preacher. +1 on
> allll of this.
>
Well, I haven't got a proposal to rip out compatibility checks (yet).
I'd like to give proponents of the system a chance to defend it first.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by "C. Michael Pilato" <cm...@collab.net>.
You're one offering plate short of being a great preacher. +1 on
allll of this.
Ben Collins-Sussman <su...@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
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Fri, Dec 03, 2004 at 05:13:50PM -0500, Greg Hudson wrote:
> On Fri, 2004-12-03 at 16:05, Mark Benedetto King wrote:
> > When/if enterprising entities implement their own fs backend
> > or ra modules, they'll want some sort of API/ABI stability, so
> > that they don't have to constantly roll new releases.
>
> We don't claim to support that.
>
> > I recognize that there aren't any examples of this yet, but
> > we went through all the trouble of building the RA and FS
> > loaders; we have to expect that someday there will be
> > third-party modules.
>
> We have RA and FS loaders so that Subversion binary packages can be
> separated out into multiple components, so that the main package doesn't
> have to depend on BDB and neon.
>
> (That may not have been the original reason for the RA loader, but
> that's the benefit we derive from them now.)
>
I had assumed the packaging modularity was a freebie, and that
extensibility was the original intent. You're right though; we
don't have any way for the user to load their own modules, so
there's obviously no way to extend the system.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-12-03 at 16:05, Mark Benedetto King wrote:
> When/if enterprising entities implement their own fs backend
> or ra modules, they'll want some sort of API/ABI stability, so
> that they don't have to constantly roll new releases.
We don't claim to support that.
> I recognize that there aren't any examples of this yet, but
> we went through all the trouble of building the RA and FS
> loaders; we have to expect that someday there will be
> third-party modules.
We have RA and FS loaders so that Subversion binary packages can be
separated out into multiple components, so that the main package doesn't
have to depend on BDB and neon.
(That may not have been the original reason for the RA loader, but
that's the benefit we derive from them now.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Fri, Dec 03, 2004 at 03:07:57PM -0500, Greg Hudson wrote:
> I'd say, feel free to change the private FS vtable in any way you want.
> If we don't have a mechanical check which prevents mixing, then that's
> arguably a problem we should fix, but we've never publically guaranteed
> that you can mix versions of libraries within the svn package.
>
When/if enterprising entities implement their own fs backend
or ra modules, they'll want some sort of API/ABI stability, so
that they don't have to constantly roll new releases.
I recognize that there aren't any examples of this yet, but
we went through all the trouble of building the RA and FS
loaders; we have to expect that someday there will be
third-party modules.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Why do we allowed mixed versions of libsvn_* ?
Posted by Greg Hudson <gh...@MIT.EDU>.
I'd say, feel free to change the private FS vtable in any way you want.
If we don't have a mechanical check which prevents mixing, then that's
arguably a problem we should fix, but we've never publically guaranteed
that you can mix versions of libraries within the svn package.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org