On 12.07.2012 18:31, Peter Samuelson 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
> 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.
What? There definitely is, specifically in the case of the working copy
library. Not on the API level, of course, but that's hardly where the
WC-version problem stems from. That's why you have GUI clients that
contain copies of several different versions of SVN's client libraries
and pick the correct one depending on the version of the working copy
they happen to be dealing with at any particular moment.
And really, there's no reason why the Subversion command-line client
shouldn't do the same thing -- in fact, this is by far the easiest way
to support multiple working copy formats, even if it is less than
optimal as far as installed binary size is concerned (not to mention
release management and version juggling and testing).
Certified & Supported Apache Subversion Downloads:
Received on 2012-07-13 11:32:53 CEST