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

Re: Boost SVN adoption with Eclipse support

From: Patrick Mayweg <mayweg_at_qint.de>
Date: 2004-01-13 07:22:00 CET

Hi John,
John Pybus wrote:

> Fernando.Colombo wrote:
>> I think it's pretty obvious that SVN adoption would be dramatically
>> boosted
>> if Eclipse has a nice support for it.
>> Although subeclipse does this, it's poor if compared to Eclipse
>> support on
>> CVS. svn4eclipse wants to do this, but it's a student project, and
>> tend to
>> be very slow.
>> Perhaps if Eclipse.org and Tigris.org join efforts, SVN integration
>> would be
>> part of "The Eclipse Project" itself... (a dream to me)
>> The guys at Eclpise.org like SVN, but they need a good Java
>> integration to
>> make it real. Currently, SVN integration with Java has the following
>> options:
>> 1. JNI (javahl, SWIG-Java)
>> 2. Command line (Alternate Computing jsvn bindings).
>> Both aren't practical for Eclipse.
>> Option 1 (JNI) needs platform specific Java libraries. "The Eclipse
>> Project"
>> supports 7 platforms. As far as I know, only SWT subproject requires
>> platform specific Java libraries. The rest is 100% pure Java,
>> including CVS
>> support.
You need just 6 Java libraries. The 2 linux platforms need the same library.

>> Option 2 (command line) does not provide enough flexibility, like safe
>> process aborting and process state inquiring capabilities.
>> They need a 3rd option - a 100% pure Java option. This is essentially
>> a Java
>> implementation of the SVN protocol (client-side only). Perhaps this
>> is the
>> missing project in the SCM category of Tigris.org.
> This ought to be a FAQ.
> Replacing client-side svn is a lot harder than writing a pure java CVS
> implementation. The svn WC is more complex, and probably the network
> protocols too. I doubt that this would be fruitfull. It might be
> somewhat easier to write a new incompatible WC format, and reimplement
> (one of) the network protocols, though I don't think that would be as
> useful.

I do not see any way to support the file: protocol, without porting
BerkeleyDB to java too. The only supported access I know of uses JNI as

> Far more useful would be to ship a good, stable set of JNI bindings
> with svn- (or whatever it'll be called :), and to apply the
> same set of strong API compatibily promises that the C svn libraries
> do. This would allow java tools to integrate with svn to almost the
> same degree as natively compiled ones. Really, library integration,
> and hence widespread tool development, is more about stable API and
> ABI promises than particular technologies.

The current javahl is stable as possible. I have only added new
features. The only other changes have been things like new actions and
states, for which a mapping has been added. What additional features do
you need for javahl?

> Yours,
> John
> (who doesn't use Eclipse much, but supports a team who do)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 13 07:20:48 2004

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

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