On Feb 25, 2005, at 8:29 AM, C. Michael Pilato wrote:
> Thomas Singer <firstname.lastname@example.org> writes:
>> JavaSVN is an outstanding library! Alex created it in only a half
>> year from zero - that is absolutely amazing and shows the power of a
>> very good developer armed with a very good programming language.
> "From zero", huh? I'm fighting the urge to be offended.
> How about, "from the results of a team of very good developers
> spending a few years working out all the hard design and theory
> problems first." When was the last time actually typing code -- in
> any language -- was the hardest part of software development? Punch
> cards? Toggle switches? Perl 5?
No need to get harsh. :-)
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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Feb 25 16:44:22 2005