Thanks for your useful explanations.
Mark Phippard wrote:
>JP Fiset <jp@fiset.ca> wrote on 09/20/2005 09:49:22 AM:
>
>
>
>>Would there be possible design changes to javahl that would alleviate
>>
>>
>the need
>
>
>>to change the libraries on every minor revisions? I am thinking of
>>
>>
>something
>
>
>>like passing XML docs, or something equivalent, between the JAR and the
>>
>>
>native
>
>
>>library. That would mean that the list of parameters would stabilize,
>>providing better binary compatibility between revisions.
>>
>>
>
>You are misunderstanding. I am saying that the JAR could be from 1.2.0
>and the library from 1.2.3 (or vice versa) and they would work fine. You
>just cannot take a JAR from 1.1.x and use it with a 1.2.x library and vice
>versa.
>
>JavaHL uses JNI so the interface contract is fairly tight.
>
>Finally, we are driving JavaHL pretty hard and constantly demanding new
>features so we generally demand the very latest version in Subclipse. I
>do not see that changing for a while.
>
>
>
>>Ideally, the native library should get shipped with Subversion itself,
>>
>>
>freeing
>
>
>>the end user's need to fetch them. Are there technicalities that I am
>>
>>
>missing
>
>
>>why this can not be done? Memory management issues? Compiler selection?
>>
>>
>
>There are no technical issues with this approach, it is simply that in the
>case of Linux this is entirely under the control of the distribution
>provider. There are no Subversion "binaries" for any platform other than
>Windows. A company named Metissian has been providing them for OS X, but
>in the Linux world it is up to the distro. Historically many
>distributions will not include any software that requires Java because of
>the licensing issues. This is getting better and there are more and more
>options for JavaHL being made available in the distros.
>
>
>
>>Yes, I agree that the XML flavours of the commands will make for more
>>
>>
>reliable
>
>
>>parsing of the results. Would you mind enlightening me on the
>>
>>
>complications of
>
>
>>advance commands where dodginess is expected even if XML results are
>>
>>
>provided?
>
>No, the issue is that right now most of the commands do not have an --xml
>option. Once they all do, I would expect this issue to get a lot better.
>This adapter will always be the slowest but it should be possible for it
>to become a lot more reliable.
>
>Mark
>
>
>
>_____________________________________________________________________________
>Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
>_____________________________________________________________________________
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
>For additional commands, e-mail: dev-help@subclipse.tigris.org
>
>
>
>
Received on Wed Sep 21 00:12:56 2005