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...@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 <pe...@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