> -----Original Message-----
> From: Peter Samuelson [mailto:peter_at_p12n.org]
> Sent: donderdag 12 juli 2012 19:31
> To: Markus Schaber
> Cc: dev_at_subversion.apache.org
> Subject: Re: Format bump for 1.8?
>
>
> [Markus Schaber]
> > So my personal experience tells me that multiple-client scenarios are
> > the common case, and that the deployment strategy (only using linux
> > distro packages, or 3-in-1 bundles like VisualSVN) can reduce that
> > problem.
>
> So, we provide a pile of libraries that maintain ABI backward
> compatibility. You can have as many different svn client apps on a
> given system as you want, and so long as they are all using the same
> copy of our libraries, there is no cross-version compatibility problem.
>
> (Of course, there's two other related issues: 1) sharing a wc across
> two or more systems; 2) use of SVNKit. I'll ignore both for now;
> SVNKit in particular is, and should be, Somebody Else's Problem anyway.)
>
> But IMO, we need to encourage using a _single_ copy of the Subversion
> libraries for all your clients. As you noted, that's how things work
> in integrated OSes like Linux distributions. It is unfortunate that
> the Windows world has a long cultural history of bundling dependencies
> into every installer, which obviously works against this goal.
>
> Is there some way we could push back? Encourage downstream developers
> to settle on a common libsvn installation? If they have to bundle it
> for ease-of-installation purposes, can they do so in such a way that,
> from a system perspective, it's two independent components? Basically
> bundle a common libsvn _installer_, instead of bundling libsvn (and of
> course apr / apr-util / apr-iconv and their dependencies) into your
> base package?
>
> I think there's precedent for this approach - e.g., the way some
> Windows installers will bundle a copy of VC++ runtime libraries, or the
> .NET CLR, in case you don't have a new enough one already.
>
> But I suppose for this to be workable, we would have to stop relying on
> third parties to build our Windows installers, and actually build one
> ourselves. Is this feasible?
This sounds like, let's break compatibility to introduce a new kind of
compatibility to me.
Given that on Windows several Subversion distributions use different C
runtimes I don't think it will be easy to reach consensus.
The distributions that switch to a central installation first are the most
likely to break when they encounter other installations.
And installing in a central location will introduce even more problems,
because libraries like openssl and zlib have incompatible versions in the
wild.
(We found lots of them when we tried using a central installation in AnkhSVN
0.X and 1.X)
I'm not looking forward to this process. The SlikSvn binaries explicitly
took the opposite approach: Make sure there are 0 library name conflicts, by
giving every shared library a product prefix.
Bert
Received on 2012-07-12 22:21:31 CEST