I am hosting a number of projects using Subversion. The tools I like to
use are Subversion, Ant and Eclipse. People that I work with require to
install the following packages: Java, Subversion and Ant. All other
tools/components can be checked in subversion, like svnAnt and JavaSVN,
and delivered with the project itself. I like to set up projects so that
as little need to be installed on the developer's end: it decreases my
involvement in setting up a new developer.
Lately, I started to implement a feature for svnAnt. It has given me a
better understanding of the challenges in the subversion/subclipse
projects. This has led me to some reflections and a number of questions.
Mainly, what is the future path for svnAnt, and Subclipse, when it comes
to the client adapter?
There seems to be a number of "cons" on all counts:
* JavaSVN: This is my favourite approach, because it is developped
in Java and can be distributed without worries about the nature of
the end platform. However, the licensing issues/changes that are
coming might prevent me from including the jar in my projects. Am
I reading this right?
* JavaHL: So far, there seems to be necessary steps required on the
user's end, since libjavahl.dll/so does not ship with Subversion.
Also, it appears that libjavahl.dll/so and javahl.jar must match.
In any case, this does not seem as portable. Is it in the plans to
get to a situation where libjavahl.dll/so will be shipped with
Subversion and a standard javahl.jar can be shipped with projects,
regardless of the end user's Subversion installation?
* Command Line Interface: There are a number of posts that suggest
to stay away from it because they claim it is buggy.
What is the feeling of the developers on this list as to the long term
direction of those client adapters?
Received on Tue Sep 20 01:14:03 2005