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

Re: Why do we allowed mixed versions of libsvn_* ?

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-12-04 12:26:06 CET

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
Received on Sat Dec 4 12:26:44 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.