On Thu, Jul 12, 2012 at 10:56 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Thu, Jul 12, 2012 at 22:19:50 +0200:
>> 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 :-)).
>>
>
> I don't think there is antagonism against svnkit here; just "they chose
> not to use our APIs, so if things break because of that it's their
> problem to fix and not ours".
To restate what I said on IRC: things are not breaking because of
SVNKit (they easily support all working copy formats back to 1.3 with
their 1.7 client), it's because of the native clients :-), that insist
on upgrading themselves (nagging the user that there is a new version
that they should upgrade to) and on upgrading the working copies.
Combined with the fact that some software of the user depends upon
SVNKit for their svn support, and SVNKit's release was lagging behind
for 1.7.
But I'm trying to state the problem more generally: most users have
different clients, and those can have different release cycles. For
whatever reason. I think it's naive to ignore that problem.
>> 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.
>>
>
> Of course you can, just don't install it to the same $prefix as
> everything else. On svn.apache.org we have 6 different svn
> installations...
Okay, maybe I can. But it's hard, especially because I'm not a
sysadmin myself on that system, can't build from source, so I have to
depend on installable third-party packages (Solaris packages in this
case). But okay, maybe this is going a bit in too much detail about my
particular situation ... don't want to bring in my organizational
problems into the equation :-) ...
But on Windows, I could just zip some svnclient from another system,
and unzip it into C:\Temp or whatever, and test whatever I want.
--
Johan
Received on 2012-07-12 23:30:00 CEST