views:

139

answers:

3

Hi,

I used ikvmc to compile svnkit to a C# (dll) library and linked it as a reference to my project.

I tried a proof of concept code to checkout:

public void checkOut(Dictionary<string,List<object>> tokens) {
            string url_str = (string) tokens["checkout"][0];
            setupLibrary();
            java.io.File path = new java.io.File(Path.Combine (Directory.GetCurrentDirectory (), "check_out_folder"));

            SVNURL url = SVNURL.parseURIEncoded(url_str);

            SVNClientManager cm = SVNClientManager.newInstance();
            SVNUpdateClient uc = cm.getUpdateClient();
            try {
                uc.doCheckout(url, path, SVNRevision.UNDEFINED, SVNRevision.HEAD, true);                        
            }
            catch (SVNException e) {
                Console.WriteLine(e.getErrorMessage());
            }
        }

Everything compiles fine, and even runs fine. However, I have this error:

$ mono subsync.exe -co http://code.djangoproject.com/svn/django/trunk/
svn: Cannot rename file '/home/nubela/Workspace/subsync/subsync/bin/Debug/check_out_folder/.svn/tmp/entries' to '/home/nubela/Workspace/subsync/subsync/bin/Debug/check_out_folder/.svn/entries'

It creates the checkout_folder, and here are the conflicting files:

$ ls -alR check_out_folder/ | grep entries
-r--r--r-- 1 nubela nubela  204 2010-02-17 13:07 entries
-r--r--r-- 1 nubela nubela  204 2010-02-17 13:07 entries

Heres are the contents of the checkout_folder:

[nubela@nubela-netbook check_out_folder]$ ls -al
total 12
drwxr-xr-x 3 nubela nubela 4096 2010-02-17 13:07 ./
drwxrwxr-x 3 nubela nubela 4096 2010-02-17 13:07 ../
drwxr-xr-x 6 nubela nubela 4096 2010-02-17 13:07 .svn/

Any idea why this is happening and how I can overcome this?

Edit: It works under windows (with mono, not under .NET). Prolly because windows does not have the annoying file permissions for files.

Edit2: I have chmod 777 -R checkout_folder already, and explicitly chmod 777 the 2 entries file. It still doesn't work. Weird.

A: 

This could be many things, but the first thing to point out is that the File.renameTo() javadoc says this:

Many aspects of the behavior of this method are inherently platform-dependent: The rename operation might not be able to move a file from one filesystem to another, it might not be atomic, and it might not succeed if a file with the destination abstract pathname already exists.

I'd start by looking into the following:

  1. Are you using a version of SVNKit that is compatible with your platform? I thought the it was nominally platform independent, but you should confirm that.

  2. How is the SVNKit code trying to rename the file? My guess is that it uses File.renameTo() but you need to confirm that.

  3. Is the SVNKit code trying to detect the platform type (e.g. to cope with platform specific rename behaviour) ... and getting it wrong?

  4. What is the source of the Java class library that is used by your ikvmc-ified code? Is it an OpenJDK library? A GNU Classpath library? Something else? And how is the native part of the i/o stack implemented on your platform? One theory is that the ikvmc-ified version of File.renameTo() is breaking SVNKit by behaving differently to the behaviour of the standard Java version on Linux.

Stephen C
A: 

It was a bug in SVNKit that made all non-windows setups to throw an exception.

For details: http://svnkit.com/tracker/view.php?id=360

And yes, I eventually went to look at SVNKit's source. Damn bug.

nubela
A: 

Finally, we have figured out that it is not an SVNKit bug, but rather converter one. For whatever reason, converted code was not able to rename file when destination already exist (contrary to the JVM behavior on Linux).

Adding "dst.delete();" before "src.renameTo(dst);" solved the problem (so far I'm not going to make it standard as it breaks rename atomicity - I think converter should be changed to fix this problem).

Alexander Kitaev, http://svnkit.com/

Alexander Kitaev
Your right :) I posted this solution in the bug tracker didn't I ;)
nubela