SVNKit upgrade?

So, I've heard some stories about how upgrading SVNKit is apparently difficult because nobody other than roippi understands how Mafia's driver interacts with the library.

Since the library is publicly available on svnkit.com, I decided to just check out a fresh update and just try plugging it in naively. Didn't compile right off the bat, since apparently it relies on newer versions of bundled libraries, namely trilead-ssh2 and sequence-library.

Once I added the new JARs and removed the old ones, it just compiled without a hitch. I haven't done very thorough testing, as most scripts on svn are currently unavailable, but I did a reinstall of Guide (delete / checkout) and confirmed that the svn folder is now compatible with svn 1.8.

I don't remember all of the details, because when roippi decided to take the idea and run with it, I was lazy enough to let him. But there was some problem with the jar files working as is and as a result we imported the source as \KoLmafia\lib\org\tmatesoft\svn and compiled after some local modifications. If I had to guess it may have been a KoLmafia requirement, at the time, to be source code and runtime compatible with an older version of Java. So if we do update we should consider removing the source we have replicated and replacing it with a jar (and then we can have discussions about moving from ant to maven as a build tool) and making sure the results execute under Java 1.5 which I think is the end user environment we have actually committed to supporting.

On a personal note, I am constrained to access SVN 1.7 repositories that are not in my power to upgrade on a couple of machines I also use for mafia. I would appreciate it if mafia managed svn directories could remain at 1.7, possibly by a user opt-in override, so I can maintain just one set of tools locally ;-)

I installed the entire svnkit binary installation (v 1.8.7), and the bundled jsvn executable handles both versions of repositories.
I have it in $HOME/take/svnkit, and symlink $HOME/bin/jsvn as $HOME/take/svnkit/bin/jsvn, and that appears to Just Work (TM) (R).
(I remember that I downloaded it after googling svn clients that can handle multiple local repository versions, but can't replicate the search)

IIRC I installed it the way I did in order to minimize JAR size. I managed to manually strip out some dependencies somewhere.

If it's not playing well with current CLI tools, feel free to do what's needed to upgrade it. Though honestly the fact that each SVN release creates this backwards-compatibility nightmare is pretty ridiculous in itself.

While, as xKiv mentioned, SVNKit will automatically detect the working copy format, when checking out new repositories, it defaults to checking out repositories using format ISVNWCDb.WC_FORMAT_18, which is compatible with svn 1.8.

There doesn't seem to be an overloaded method for invoking doCheckout with a specified working copy format, so I added said overloaded method myself. Apparently SvnUpdate.doCheckout is invoked in two separate places, which I believe can be consolidated (I've done so locally).

Given all that, I've written a rudimentary system for checking the integer preference "svnFormat" and passing that to my overloaded function. For use with svn 1.7, you'll want to set svnFormat = 29.

The extent of my testing has been checking out Guide, using svn in my shell to check the working copy format, setting svnFormat, deleting Guide, checking out Guide again, and checking the working copy format again. It seems to work.