[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] JavaHL, JavaSvn, Command Line Interface; the way ahead?

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2005-09-20 16:00:27 CEST

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
> like passing XML docs, or something equivalent, between the JAR and the
> 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

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,
> the end user's need to fetch them. Are there technicalities that I am
> 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
> parsing of the results. Would you mind enlightening me on the
complications of
> advance commands where dodginess is expected even if XML results are

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.


Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Wed Sep 21 00:00:27 2005

This is an archived mail posted to the Subclipse Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.