Home/ Questions/Q 3395166
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T04:15:27+00:00

I’m writing a desktop app that must work on both Linux and Windows because

  • 0

I’m writing a desktop app that must work on both Linux and Windows because on Windows I need to use JNI to implement a functionality. But that’s not the problem.
I have a Windows and a Linux installation of the Eclipse IDE and I use Subversive to commit to my repository.
After a Windows commit I started working on Linux to implement the linux implementation but I find myself with a conflict:

.classpath [Working]

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="src" path="src"/>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/>
    <classpathentry kind="lib" path="lib/sqlitejdbc-v056.jar"/>
    <classpathentry kind="output" path="bin"/>
</classpath>

.classpath[Repository]

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="src" path="src"/>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/>
    <classpathentry kind="lib" path="lib/sqlitejdbc-v056.jar">
        <attributes>
            <attribute name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY" value="QuickBackup/bin"/>
        </attributes>
    </classpathentry>
    <classpathentry kind="output" path="bin"/>
</classpath>

As you can see the conflict is in the <attribute>...</attribute> part which is used to tell the jvm where is my dll module to use with jni. Why? Coundn’t Subversive just update the working version?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You have 2 problems with different nature. First, svn conflict arises if you modify file from working copy with rev 156, but in the meantime this file from someone else’s working copy was committed to rev 157. When you update your file, two scenarios can occur:

    • merged (G): means that you and your colleague were working on the file but on different places, so the ‘diff’ utility thinks it is OK to merge it.
    • conflict (C): the ‘diff’ utility determined that both yours and your colleague’s changes were incompatible, so you’ll need to resolve the differences on (only) yours working copy

    The second problem is ini (or conf) files that are not deployment-agnostic. What I mean is, this file should be different on each machine where the code is deployed. In this case (and I think this is your case) you’ll need to put svn:ignore property on it, and remember to create this file and put its specifics on every deployment.

    http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.3

    • 0