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
