Export to GitHub

subsynct - SvnkitDLL.wiki

SVNKit

As you guys should know by now, we have changed our library to interface SVN from svndotnet to SVNKit.

Svnkit is a Java library. How the hell are we using it? Feel free to read the epic story below:

How to use

  1. Update your repository to the dev folder in the trunk. (You can also remove all svndotnet now)
  2. Remove svndotnet project references from subsync project
  3. Download IKVM binary from http://sourceforge.net/projects/ikvm/files/
  4. Dump the IKVM DLLs into .../subsync/Contrib/DLL/
  5. Add IKVM DLLs and svnkit's DLLs into assembly reference
  6. Build and run.

Note

When I tested in Windows, I realised that my app only ran with a mono wrapper. Meaning I had to browse to the mono installation, and do a mono.exe subsync.exe -co some-url for it to work.

There has gotta be a way to fix this. Let me know when you guys figured it out. But otherwise, its known to be at least working in some form. Much better than any other methods we have tried so far.

Further Readings

Epic Story

You guys have no idea what I amazing stuff I just did. And I'm gonna share because its an EUREKA moment right now!

For the past few days, I had lotsa shit with the subversionsharp, or svndotnet library. They were just too poorly designed. Then I took a look at Monodevelop's source code to see how they implemented their version control, I was already coming down to a decision to base on that, and write our own library. That was how adamant and pissed I was.

Then after some crazy caffeine high, I couldn't sleep. I researched and researched. And I found ikvm (ikvm.net). This is the most amazing thing ever. It converts a Java library into a c# usable library.

With that in mind, we now have SVNKIT. Which is another amazing thing. Because with that, we don't even have to install a SVN backend, because it is a pure subversion client replica in itself. It is fully compatible with the latest subversion. So that means NO DEPENDENCY HELL. Then I converted it to DLL, added it to assembly reference, and for HOURS and HOURS (4 hours to be exact), I couldn't get it to work. It worked on Windows, just not on Linux. You can see my stackoverflow page herehttp://stackoverflow.com/questions/2278485/svnexception-unable-to-ren... asking about it. I was pretty darn pissed by then. All the talk about cross platform and it jsut plain didnt wanna work on Linux. What the hell.

After hours and hours of googling. I gave up, and did what I hate doing, debug. I downloaded SVNKIT's source code, did a GREP to find out which file was in charge of renaming method.

I found it, and heres the offending code:

boolean renamed = false; if (!isWindows) { renamed = src.renameTo(dst); } else {

This goddamn piece of code, broke every non windows renaming. All because it forgot to add a renamed = true after performing the deed! So I changed it to:

boolean renamed = false; if (!isWindows) { //its not windows renamed = src.renameTo(dst); renamed = true; } else {

Compiled it. Reconverted the compiled .jar files into a .dll assembly. And BAM.

NOW IT ALL WORKS.

We now have SVNKIT, a fully functional high level Java SVN Client Library to work with, in C#.