On Thu, Jul 12, 2012 at 7:31 PM, Peter Samuelson <peter_at_p12n.org> wrote:
> [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.)
I think it's sad that there is so much antagonism against SVNKit in
this community. With my svn user hat on, I consider SVNKit as just
another part of the svn ecosystem. As a user, I don't really care if
it's implemented in C, in Java or in Turbo Pascal :-), as long as it
plays by the rules and acts like any other svn client. Besides, in our
environment I have no choice but to use SVNKit: the svn plugin of my
IDE (IntelliJ IDEA) only works with SVNKit.
I think it would be beneficial for the svn ecosystem as a whole if
this community would try to build better relations with the SVNKit
people. Some mutual understanding certainly wouldn't hurt. I was very
happy to see more interest by the SVNKit guys in the core project, and
see their presence at the Berlin Hackathon (hi Dmitry :-)).
> 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.
I guess this is theoretically possible. But as a Windows user, I
personally wouldn't like it. This is exactly one of the things that
annoys me every time when I'm working on e.g. Solaris: What? I can't
have two different svn versions installed at the same time? On my
central build server with 1000 working copies I can't just quickly
install a 1.7 version to do some tests, while all my colleagues keep
on running svn 1.6 for the real stuff. Gah.
--
Johan
Received on 2012-07-12 22:20:43 CEST