Hello Ken,
> I am using only http access, and JavaSVN(1.0) was working
> great. The only reason I wanted it to use JavaHL is because of this:
> http://subclipse.tigris.org/faq.html#adapter
To be honest there are known bugs in native Subversion that fixed in
JavaSVN, and also number of bugs in JavaSVN 1.0.0 that are not present in
native Subversion (however known bugs are fixed in repository version). Most
of the users will never be influenced by these bugs, and they are not
critical (doesn't result in data loss or working copy corruption).
All these bugs reveal themselves in a very specific situations (e.g. complex
working copy state or complex updates) or environment. As far as I could
suggest ant scripts usually do things like checkout everething, do something
with a working copy, create a tag in repository, etc. I would consider such
use cases as simple ones, so as long as JavaSVN works for your usual test
case, it probably will continue to work again and again :) Same is correct
for JavaHL of course. Also, JavaSVN perform diff operation (patch
generation) much faster then JavaHL, but this benefit only visible on large
text files, those large then 1 MB.
Of course JavaHL has larger audience then JavaSVN, but JavaSVN's one is not
small at the same time - it is used by some of Subclipse users, IDEA users,
SmartSVN users and number of smaller server-side and client-side
applications. This makes me think that there are no critical bugs at the
moment, though I will never say that JavaSVN is bug free.
So, I defenitely agree with the text posted at Subclipse page - "Of course,
since JavaSVN does not utilize the Subversion libraries it does not have the
guaranteed compatability that you can expect from JavaHL", but would like to
add that so far, with version 1.0.0, the number of incompatibility bug
reports is close to zero.
Please don't get me wrong, I'm not pressing on using JavaSVN instead of
JavaHL, just would like to advertise JavaSVN a little bit :))
Alexander Kitaev,
TMate Software,
http://tmate.org/
http://jetbrains.com/tmate/
> -----Original Message-----
> From: Ken Nakamura [mailto:knakamur@tripwire.com]
> Sent: Friday, November 11, 2005 00:20
> To: users@subclipse.tigris.org
> Subject: RE: Re: libsvnjavahl & svnant on solaris
>
> Thanks, Dan, but no, there are no other svn libs on the
> system. It was a clean install of Sol9 + some sunfreeware
> pkgs for gcc, autoconf...
>
> I am using only http access, and JavaSVN(1.0) was working
> great. The only reason I wanted it to use JavaHL is because of this:
> http://subclipse.tigris.org/faq.html#adapter
>
> Actually, JavaHL is working great for me, since I just went
> ahead and exported the lib path variable from my
> ~/.bash_profile. Mark Phippard's suggestion of adding it to
> Ant's launcher script would have worked as well, but I
> decided against it because I share ANT_HOME with others.
>
> Thanks, again, for the advice.
>
> -k
>
> -----Original Message-----
> From: Dan North [mailto:dan@tastapod.com]
> Sent: Thursday, November 10, 2005 2:43 PM
> To: users@subclipse.tigris.org
> Subject: Re: libsvnjavahl & svnant on solaris
>
> It sounds like you have some other svn libs elsewhere (and hashed
> earlier) in your loader path. Do you have a Solaris pkg or
> rpm already installed for subversion?
>
> Of course this all becomes moot if you use the lovely javasvn client.
> Even if you have a file:/// repository, running a local
> svnserve process
>
> and using javasvn is a whole lot easier than getting the
> javahl voodoo to work on *nix.
>
> Cheers,
> Dan
>
> Ken Nakamura wrote:
>
> >Hello,
> >
> >I'm not sure if this is the right place for this question.
> It's an odd
> >occurrence...
> >
> >I have built my own svn-1.2.3, with javahl enabled. I'd
> like svnant to
> >use javahl; not that I don't like javasvn (props to alex k,
> it rocks),
> >but according to subclipse's faq, javahl sounds like the
> best way. I'm
> >on Solaris 9 and the svn libs are in /usr/local/lib, which I've added
> to
> >the LD_LIBRARY_PATH using 'crle'. This means that it's not
> actually an
> >environment variable, but stashed in a file,
> /var/ld/ld.config. ld.so
> >is supposed to parse it and dynamically load libs accordingly. From
> >what I can tell, this is the Solaris Way. Here's the problem:
> >
> >If I *don't* specifically export LD_LIBRARY_PATH into my
> environment,
> >svnant doesn't find the libs and resorts to javasvn. I've
> run the test
> >ant script through truss and note that it tries to stat64
> >libsvnjavahl-1.so in several locations that aren't in
> LD_LIBRARY_PATH,
> >like lib dirs under my JAVA_HOME/jre tree. I find that odd...
> >
> >So, is this a weird svnant issue? Is it the jvm? Is it my
> box? Is it
> >even really worth using javahl over javasvn, now that javasvn is at
> 1.0?
> >Should I just not care and export the lib path in my .bash_profile?
> >
> >-k
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> >For additional commands, e-mail: users-help@subclipse.tigris.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
Received on Fri Nov 11 11:05:28 2005