Johan Corveleyn wrote on Thu, Jul 12, 2012 at 23:29:06 +0200:
> 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.
>
Okay. But in that case, the problem you claim is disregarded has
nothing to do with svnkit...
> >> 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.
./configure --enable-all-static ???
>
> --
> Johan
Received on 2012-07-13 11:11:20 CEST