JP Fiset <jp@fiset.ca> wrote on 09/19/2005 11:14:03 AM:
> 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?
Any concerns/questions about the JavaSVN license agreement should be
directed to tmate.org. All I know is what is on their web site. They are
well aware that we are using JavaSVN in Subclipse and they have not said
anything to us yet. Obviously if they go to a pure commerical license we
will either need to stop including it, or just include the last version
with the BSD license. The bottom line is that until they decide what they
are going to do, there isn't much to talk about.
The main CON to JavaSVN is lack of file:// access, which I do not see as
much of a con. Apparently, Alex is looking into adding that, which raises
what has always been my biggest concern about JavaSVN and that is just
that it will introduce subtle differences with the main Subversion product
that will manifest in a bad way. They have done an excellent job avoiding
these problems so far and now that they leverage the Subversion test suite
this should be even less likely. If you plan to mix a lot of different
Subversion clients, I tend to think JavaHL is still the safest option. If
you are only going to use something like Subclipse, then JavaSVN might be
the best option. Where as I used to be about 65/35% in favor of JavaHL, I
think I am now more like 51/49%.
> 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?
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.
It is getting much. much easier to obtain JavaHL on virtually every
platform and also the build systems has been greatly improved so that
building your own is also very easy to do.
There are technical reasons why we will likely never include a JavaHL
library for any platform other than Windows.
> 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.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Tue Sep 20 01:30:05 2005