One more thing regarding JavaSVN:
Subversion provides JavaHL bindings but it doesn't fit needs of java
community well. First there are difficulties with deployment and second
JavaHL doesn't provide fine level of control over repository operations that
is needed by some applications. That is why javasvn was implemented.
I think that subversion developers, if they would consider java community
requirements as important, could provide compatible pure java subversion
implementation faster and of better quality then javasvn. From this point of
view you may consider javasvn as a contribution to the subversion project
(and me as a contributor :) or subversion subproject. BTW, there is a
project "javasvn" registered on tigris.org, but I was not allowed to use
collab.net svn repository and so I'm hosting javasvn repository paying for
the hosting myself.
As with any opensource project, you may help javasvn development, by fixing
problems in it, providing features, documentation or tests. Me and all java
developers that use javasvn will appreciate such help a lot and it is one of
the ways to make javasvn as compatible with subversion as possible. Of
course there always be a compatibility lag, as Mark wrote, but I suppose
that it will not be larger that the time it takes majority of users to
switch to the new svn version.
The other way is to "fork" pure java client project and let subversion
developers to implement such a library, but, as far as I can see, there are
no people who would like to do it. And there is always a third way of course
- just do nothing :)
Independently on the way you choose, there will be a pure java subversion
library because community needs it. The only thing that will differ is
quality of this library and time that it will take to make it, let's say,
95% compatible with native svn.
Alexander Kitaev.
> -----Original Message-----
> From: Mark Phippard [mailto:MarkP@softlanding.com]
> Sent: Friday, February 25, 2005 5:18 PM
> To: Ben Collins-Sussman
> Cc: C. Michael Pilato; dev@subversion.tigris.org; Thomas Singer
> Subject: Re: JavaSVN (Re: Subversion Branding / "whole
> product" (Was: Re: SmartSVN - a new Subversion client))
>
>
> Ben Collins-Sussman <sussman@collab.net> wrote on 02/25/2005
> 10:42:31 AM:
>
> > JavaSVN is definitely an impressive feat of reverse
> engineering, and
> > to
> > some extent I'm glad it exists. People have been asking for a 100%
> > java implementation for a long time.
> >
> > But I'm also a bit scared of it precisely because it *is* reverse
> > engineered. It took years to design svn's core libraries, and they
> > contain a lot of complex edge-cases and code paths. Those things
> > simply aren't visible when one looks at the "surface" of
> Subversion --
> > network protocols, working copy adminstrative data, etc. And Alex
> > never participated in core SVN development, so I have no
> idea to what
> > extent he understands all of those design choices and
> complexities. If
> > a bunch of knowledgeable SVN developers had spun off an effort to
> > reimplement in Java, I'd be more trusting. Instead this
> library seems
> > to have popped out of the blue, and nobody knows how accurate it is.
> >
> > So my real problem is that it's difficult for me to trust
> that JavaSVN
> > is "deeply" compatible with the core C implementation. For
> everyday
> > use-cases, it may seem to interoperate just fine. But I'm worried
> > about the potential for subtly buggy (or just different)
> behaviors in
> > the not-so-everyday use-cases. If someone were to write a
> java clone
> > of the svn commandline client that used the JavaSVN
> libraries, and then
> > demonstrated that it passed every one of our python-based
> regression
> > tests, my fears would be allayed.
>
> Ben,
>
> I couldn't agree with you more. I am fairly active in the Subclipse
> project where this is an issue. We are working to integrate
> JavaSVN as an
> option, along with JavaHL and CLI. Currently, JavaSVN has its own
> installation process that drops it in as a replacement for
> JavaHL. So
> Subclipse thinks it is using JavaHL, but it is really using
> JavaSVN. What
> we want to do is make it an option, so the user could toggle
> between them.
>
> I share all of your concerns. What he has accomplished with
> JavaSVN is
> impressive and it seems to work fairly well with excellent
> performance.
> However, I have concerns about compatability as you
> mentioned. Not to
> mention, what will be involved to add support for all of the
> new locking
> features etc... He will have lots of WC work to do, not to mention
> changes in the wire protocols etc.. It seems like there will
> always be
> issue with compatability lags to deal with.
>
> For these reasons, I will fight hard to keep JavaHL supported in
> Subclipse. That being said, our users have so much
> difficulty getting the
> bindings on *nix it is isn't like we can ignore what JavaSVN
> brings to the
> table. What I would like to see, ideally, is some effort to
> embrace the
> JavaSVN project and "bring it into the fold" so to speak. I
> think this
> would mainly entail that the sort of things that have to be
> reverse-engineered are well documented and can be verified in
> some way. If
> there are lots of edge cases those ought to be documented. I
> think for
> the most part, everything is, so perhaps this isn't so hard to do.
>
> Your idea of coming up with a way to verify using the
> existing tests is
> excellent by the way.
>
> Mark
>
>
>
>
>
>
>
> ______________________________________________________________
> _______________
> Scanned for SoftLanding Systems, Inc. by IBM Email Security
> Management Services powered by MessageLabs.
> ______________________________________________________________
> _______________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 25 18:26:32 2005