Reposting under a new thread + subject line, at Daniel's suggestion.
[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?
Peter
Received on 2012-07-12 22:20:54 CEST