Steve Cohen <scohen@javactivity.org> wrote on 02/06/2005 11:34:22 PM:
> I misspoke here. I didn't mean "statically linked". What I meant to
> ask was "is a binary RPM-based subversion installation compatible with a
> source-built javaHL". Or should both be compiled from the same code
> base? You may not know the answer to this, but maybe someone else can
> say whether they've tried this setup.
I believe there are ways to tell the build to use existing binaries for
the dependencies. In other words, it ought to be possible to use BDB,
APR, Neon etc.. from installed RPM's. You would still have to build and
install the Subversion binaries. There is a way to build to a specific
location, so you could just build to some throwaway folder and then just
take the JavaHL library out and let the Subversion libraries remain from
the RPM.
> > The only instructions Subversion provides is how to build from source.
> > They do not discuss RPM's or any packaging mechanism.
>
> Not true. See http://subversion.tigris.org/project_packages.html and
> follow the link under Red Hat Linux - down to here:
> http://summersoft.fay.ar.us/pub/subversion/latest/redhat-9.0/src/
> This is where I got all the RPMs - source and binary - from.
But that was my point. All Subversion is doing is providing a convenience
link to an individual that has provided RPM's for RedHat. You could try
contacting that person to see if he would provide JavaHL.
> Sounds like you need a Linux expert on your team. If I were one, I'd
> volunteer, but, alas, I'm just a user of Linux.
That would be great, but ultimately JavaHL is part of Subversion, so all
we can really do is keep raising the issue and hope that the people that
maintain the packages starts to include it. On the bright side, it was
only with the 1.1 release that JavaHL became "easy" to build. So maybe it
will start to make its way into packages.
> > We are mostly Java programmers here, and at least in my case I work
mostly
> > on Windows and a little on OS X. We consume the JavaHL and Subversion
> > libraries, we do not produce them. We certainly wish there was an
easy way
> > for us to distribute a binary for Linux, but there just isn't.
Hopefully
> > the work that is being put into JavaSVN will yield some fruit, but I
> > personally think JavaHL will always be the best, and safest option.
>
> Can you talk a little more about this? Or point to somewhere where this
> issue is debated? I don't know the points and counterpoints. So far I
> have refrained from trying JavaSVN, but I may decide differently if I
> don't get it going soon. I'm guessing the CVS support in Eclipse for
> Linux uses an all-java approach rather than a JNI one, right? Of
> course, I suppose the Subversion/Subeclipse team lacks the resources
> that IBM was able to throw at Eclipse and CVS.
A huge difference between Subversion and CVS is that CVS never really was
designed with an "API" per-se. So there are a whole lot of projects that
either wrapper the CVS command line or reverse-engineer the protocols.
Eclipse did the latter and did it in pure Java. It does creep up as a
problem every now and then when a new CVS version does something
unexpected in the protocol and Eclipse stops working until they patch it.
There are also other problems (maybe some of these have been fixed).
However I know that if you used another CVS client with your Eclipse
workspace, then it would hose things up for Eclipse because it didn't do
things exactly the same way as all CVS clients.
Subversion was designed to be an API from the start. They view the CLI as
just one UI that uses that API. Since the API is written in C to access
it from Java you need to use JNI. The JavaHL layer is just a thin layer
to wrapper that functionality and present it as a more OO Java-type API.
Since JavaHL is using the Subversion API you have 100% compatability and
functionality. You know that you can interchange Subclipse, the CLI or
any Subversion GUI like TortoiseSVN or RapidSVN all in the same Working
Copy because they all use the same API and libraries to work with it.
JavaSVN can be found here:
http://tmate.org/svn/
It is an attempt to take the Eclipse-style approach of reverse engineering
everything in Java. The person working on it has done a remarkable job in
a short amount of time and it generally works pretty well. Only time will
tell how well it works and how easy it is to remain compatible with the
Subversion API. The SVN devs have always discouraged the idea of doing
this as they felt that there are a lot of edge cases and dark corners in
their WC code that would be very hard to reverse engineer properly. For
the most part, these issues seem to come up from time to time with
JavaSVN, but he seems to be doing a good job tackling them. Like I said,
only time will tell. We in Subclipse are working to integrate this
library with Subclipse so that it would become a 3rd option in the
preferences that you could choose to use instead of JavaHL or the CLI. For
the time being, until we get that work done, the option the author has
come up with has been to "replace" JavaHL with a compatible API that uses
JavaSVN instead. This works, but does not allow you to easily switch back
and forth.
JavaSVN is pure Java so it uses things like the Sun JRE to carry on an
http/WebDAV conversation with the server. It is in that code that the SSL
problem exists with apache.org. Apparently it has trouble with the
certificate used on their server. The author is looking into
work-arounds. For now, if you need to commit to apache.org via https://
then you should probably stay away from this option.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Tue Feb 8 00:59:02 2005