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