McClain Looney <mlooney@gmail.com> wrote on 08/25/2004 03:21:33 PM:
> > 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.
Actually, I understand all of these issues fairly well, but I remember a
time when I was just starting and this is not at all clear to an outsider.
> > 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.
On Windows you would have to download it yourself and then figure out
where to put it. It would help here if Subclipse gave a recommendation.
You would also likely need to install the SVN command line so that you had
the DLL's needed by javahl. The SVN command line bin folder would
probably need to be added to the PATH.
On Windows, TortoiseSVN throws a big wrench into this because it ships
versions of the same required DLL's that are compiled with a newer version
of Visual C++. The DLL's then require a MS system DLL that is not in your
path. When Tortoise is running this is all OK, but when Subclipse runs
you get errors about the required DLL's missing. Since Tortoise is
installed as a shell extension, it is ALWAYS running so its version of the
DLL's are already in memory. In theory if the DLL's are in the "right
place" it will load the other versions. The "right place" ought to either
be the directory Eclipse loads from, Java loads from, or where the javahl
DLL loads from. I have not been able to figure out which one.
> > 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 understand this. My only point is that I bet a lot of people do not use
file:// or https://. It would be nice, therefore, if the javahl library
could still provide support for svn:// and http:// in the absence of the
required libraries for those other protocols. Currently, it just fails to
load if it cannot find all of its dependencies regardless as to whether
those dependencies are needed.
> > 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).
I think you missed my point slightly. I do not think javahl needs to
move. My point is that there is no reason that Subclipse cannot make its
own builds with newer features but using the rest of the released
Subversion code base. since javahl is a self-contained entity, and
Subclipse in theory distributes it, there shouldn't be issues. (Famous
last words). javahl is just not as mature as Subversion, it doesn't make
sense for it to be on the same freeze/release schedule. I can understand
if Subversion devs want to freeze what is going into their tarballs, but
why should that stop Subclipse from making its own builds?
> > 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.
I do use javahl, I used the command line for about two minutes, and only
because it took me that long to track down the problem. In my case, there
was an old copy of an OpenSSL DLL in the \Windows folder and this
prevented javahl from loading. Not easy to figure out.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Aug 26 05:43:22 2004