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
Received on Fri Feb 25 17:22:02 2005