Avoiding multiple library copies on a system

[Peter Samuelson <pe...@p12n.org>]

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

Re: Avoiding multiple library copies on a system

[Mat Booth <ma...@wandisco.com>]

On 13 July 2012 17:34, Branko Čibej <br...@wandisco.com> wrote:
> On 13.07.2012 17:21, Peter Samuelson wrote:
>> [Branko Cibej]
>>> Like I said in my response to this in the other thread -- API or even
>>> ABI compatibility is not the issue. Working copy formats, wire
>>> protocol quirks, etc. etc. are more "interesting". And I really don't
>>> think it's up to us to tell packagers how to do their stuff.
>> Well, the reason I bring it up is, if we expect everyone to bundle a
>> copy of libsvn with every app, then our hard work to guarantee ABI
>> stability is basically pointless.  The whole reason to have a stable
>> ABI is so people can upgrade libsvn without rebuilding or redownloading
>> other apps.  At some point we must have thought that was important.
>
> This does not happen on properly managed (U|Li)nux distributions. It
> does happen on Windows, simply because there is no generally accepted
> location for globally shared libraries. Or rather, while Windows does
> provide mechanisms for component registration, they're a total pain in
> the unmentionables to use and don't apply co common or garden shared libs.
>
> Which brings us back to my assertion that it's not our job to do what
> packagers do best anyway.
>
> -- Brane
>
> --
> Certified & Supported Apache Subversion Downloads:
> http://www.wandisco.com/subversion/download
>

I believe the correct way to avoid dependency bundling on Windows is
by using side-by-side assemblies (WinSxS) like the Microsoft C/C++
runtime re-distributables do. Almost no-one uses it or even knows it's
there, however. Probably because it's a kind of black magic that
no-one cares to learn about, the path of least resistance is to just
bundle the DLL. It's also been my experience that DLL resolution using
WinSxS can be a bit flakey -- especially on Windows XP -- leading to
failures to dynamically load DLLs that link to DLLs that are in
WinSxS. This tends to lead to misleading and difficult to debug bug
reports for which I may need to book another appointment with my
psychiatrist :-)

Interestingly even Microsoft have now stopped using it for their C/C++
runtimes starting from the 2010 version:
http://msdn.microsoft.com/en-us/library/dd293574.aspx

-- 
Mat Booth
Software Engineer
WANdisco, Inc.
http://www.wandisco.com

Re: Avoiding multiple library copies on a system

[Branko Čibej <br...@wandisco.com>]

On 13.07.2012 17:21, Peter Samuelson wrote:
> [Branko Cibej]
>> Like I said in my response to this in the other thread -- API or even
>> ABI compatibility is not the issue. Working copy formats, wire
>> protocol quirks, etc. etc. are more "interesting". And I really don't
>> think it's up to us to tell packagers how to do their stuff.
> Well, the reason I bring it up is, if we expect everyone to bundle a
> copy of libsvn with every app, then our hard work to guarantee ABI
> stability is basically pointless.  The whole reason to have a stable
> ABI is so people can upgrade libsvn without rebuilding or redownloading
> other apps.  At some point we must have thought that was important.

This does not happen on properly managed (U|Li)nux distributions. It
does happen on Windows, simply because there is no generally accepted
location for globally shared libraries. Or rather, while Windows does
provide mechanisms for component registration, they're a total pain in
the unmentionables to use and don't apply co common or garden shared libs.

Which brings us back to my assertion that it's not our job to do what
packagers do best anyway.

-- Brane

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: Avoiding multiple library copies on a system

[Peter Samuelson <pe...@p12n.org>]

[Branko Cibej]
> Like I said in my response to this in the other thread -- API or even
> ABI compatibility is not the issue. Working copy formats, wire
> protocol quirks, etc. etc. are more "interesting". And I really don't
> think it's up to us to tell packagers how to do their stuff.

Well, the reason I bring it up is, if we expect everyone to bundle a
copy of libsvn with every app, then our hard work to guarantee ABI
stability is basically pointless.  The whole reason to have a stable
ABI is so people can upgrade libsvn without rebuilding or redownloading
other apps.  At some point we must have thought that was important.

And if we did manage to achieve an ecosystem in which people are not
bundling libsvn, the problem of multiple libsvn versions talking to a
single wc would be greatly reduced.  (Maybe not completely eliminated,
as there's still the case of a wc on a network filesystem accessed from
multiple clients machines.)  That is why I wondered if there's any way
we can get there, by encouraging people to take advantage of our ABI
stability feature, which as I said we really do work hard to maintain.
But it sounds like a lot of people really do prefer the vertical
approach (every app bundles every library), in the Windows world, and
there may not be much we can do about it.

Peter

Re: Avoiding multiple library copies on a system

[Branko Čibej <br...@wandisco.com>]

On 12.07.2012 21:20, Peter Samuelson wrote:
> 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.

Like I said in my response to this in the other thread -- API or even
ABI compatibility is not the issue. Working copy formats, wire protocol
quirks, etc. etc. are more "interesting". And I really don't think it's
up to us to tell packagers how to do their stuff.

-- Brane

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download