On Wed, 25 Aug 2004 14:51:23 -0400, Mark Phippard <markp@softlanding.com> wrote:
> I think the issue is fairly complex and it is hard to understand all of
> the ramifications. I would feel better about it if javahl were more
> consistently available. I think you would want to at least make a
> commitment to making a version available for download from the subclipse
> site.
yes, this is the main issue. javahl is a stepchild of subversion, is
barely integrated into the build system, and not often included by
packagers. and this is after major build system integration
improvements in 1.1. none of the svn core contributers use it on a
regular basis (if ever). The only svn committer i know of that does
anything on it is its maintainer, Patrick Mayweg (take this with a
grain of salt, this is from an outsider looking in).
> I think it is also confusing how javahl relates to Subversion itself. Does
> javahl contain everything you need, or does it also need the svn command
> line?
javahl is the preferred method of hooking into svn. it doesn't require
the commandline, but the commandline is usually available on a system
with javahl installed as well.
> What are the installation requirements for each platform? How would
> Subclipse find it? Presumably it needs to be in the PATH?
on unix systems, libsvnjavahl-1.so is put into PREFIX/lib, which is
usually on the ld loader path, and should be visible to java
applications. lord knows what happens on windows.
> The relationship of javahl to the required DLL's/libraries is always
> confusing. I wish you could get a version that did not require BDB since
> I doubt most users need it. Likewise, if you are only using svn:// or
> http:// protocols you really do not need any of the required libraries. It
> would simplify things greatly if it could handle this.
many users use file:// repositories, which _do_ require bdb (usually,
unless --fs-type fsfs is specified when the repo is created). the
relationship between javahl and the core svn libs is that javahl
provides hooks such that java code in subversion can call out to the
core svn systems to execute svn-related functionality. all svn stuff
is done through svn's own libraries.
> I have always felt that having a version of javahl controlled by Subclipse
> is advantageous as new methods can be added independent of the Subversion
> release schedule. Since it is only exposing API already present in
> Subversion it can, in theory, really be updated on its own schedule. It
> might really complicate Subclipse if it does not have the flexibility of
> adding in new features and just delivering it with Subclipse. How do you
> really control the version you are working with if you do not deliver it?
Yes, i think it would be nice for us to control javahl, as 1 of the
major user of this library. As it sits, we _do_ get alot of
functionality added to javahl, and have to date contributed tons of
code to it already. separating javahl would add its own set of
complexities, and not really change anything except for the code
contribution model (which works reasonably well already).
> Finally, I am unclear on the long term positioning of the use of the
> command line client in Subclipse. Is it here to stay? My only
> experiences with it have not been great. It feels slower, and I hate the
> DOS boxes popping up all over the place.
I personally would love to see it disappear, but I understand there
are people who use it heavily. javahl is preferred due to its speed,
and reliability. the cli client is slow due to its string parsing,
forking and fragile as well (it can break if any log output from svn
changes from release to release).
if you can get javahl on your system, you will appreciate the huge
difference it makes.
--
McClain Looney
m@loonsoft.com
Received on Thu Aug 26 05:21:33 2004