[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: JP Fiset <jp_at_fiset.ca>
Date: 2005-09-20 15:49:22 CEST

Mark Phippard wrote:

>We ship the Windows DLL, and Subversion makes it available for download.
>The dependency between the JAR and the native library is fairly loose.
>They just have to be the same major/minor version. It doesn't matter on
>what platform the JAR was produced which is why we are able to distribute
>it with Subclipse without problem.
>
>
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.

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?

>
>
>>Command Line Interface: There are a number of posts that suggest to stay
>>
>>
>away
>
>
>>from it because they claim it is buggy.
>>
>>
>
>My take is that this adapter was developed at a time when JavaHL was a lot
>harder to get and even build yourself. If that were not the case, and
>especially if JavaSVN existed, it probably never would have been
>developed. For those reasons, I would almost love to see us drop it just
>for maintenance reasons. That being said, Subversion is adding a lot more
>--xml support in their commands in 1.3. This should make it possible to
>develop a much more reliable command line adapter should someone choose to
>do so.
>
>I think the command line adapter is pretty well suited to most of the
>things someone using svnAnt would typically need to do. It is mainly in
>some of the more advanced things that Subclipse needs to do where it
>starts to get dodgy.
>
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?

Thanks,

JP
Received on Tue Sep 20 23:49:22 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.