McClain Looney <mlooney@gmail.com> wrote on 08/24/2004 12:31:44 PM:
> I propose removing the native libraries from the subclipse project,
> instead depending on the user to have a proper svn installed, combined
> with lobbying packagers of the svn releases to include javahl in their
> packages.
>
> The current situation causes a great deal of pain for users
> (especially linux and osx users) due to linking problems and conflicts
> with other installed instances of svn (tsvn et. al.). Additionally,
> the javahl build system has been mostly integrated into the svn build
> system (though is not built by default for some reason) (and is
> currently broken for osx and linux in rc2).
>
> It may be worth the time and energy to instead write a custom
> installer for subclipse that verifies that svn is installed, and that
> javahl or the commandline is available.
>
>
> Comments?
I have several.
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.
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?
What are the installation requirements for each platform? How would
Subclipse find it? Presumably it needs to be in the PATH?
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.
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?
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.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Aug 26 04:51:23 2004