Hello Ben,
I really would not like to participate in the discussion where people
discuss my skills as a developer :) and whether it is correct or not to
reuse all the core subversion team knowledge and ideas reflected in
subversion source code. There is a certain demand in java community for this
library and it justifies its existence well.
But, regarding python tests I would like to let you know that I'm already
using (again, taking advantage of core subversion team work) these tests for
JavaSVN. There is a small subset of commands implemented already and so far
all "basic", "commit", "update" and "status" tests pass (except those
related to locking, because JavaSVN doesn't support it at the moment). My
ultimate goal is to make all tests pass and I'm sure it will happen
eventually.
I do not consider subversion client library implementation to be a complex
or impossible task (but it is of course not a small task) and my way of
illustrating it is just writing a code the way I'm able to do it. I'm not
participating in "dev" community mainly because I found it easier for myself
to find answers to the questions I have by looking into subversion code or
tests.
Also, I fully acknowledge that though JavaSVN library fits many use-cases
well, there is still a lot of work to be done to make it come closer to the
quality and performance of native subversion client. And I do appreciate a
lot huge amount of excellent desing and coding that was done by subversion
developers to provide a great product.
Alexander Kitaev.
> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: Friday, February 25, 2005 4:43 PM
> To: C. Michael Pilato
> Cc: dev@subversion.tigris.org; Thomas Singer
> Subject: Re: JavaSVN (Re: Subversion Branding / "whole
> product" (Was: Re: SmartSVN - a new Subversion client))
>
>
>
> On Feb 25, 2005, at 8:29 AM, C. Michael Pilato wrote:
>
> > Thomas Singer <subversion@smartcvs.com> 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: 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 17:20:57 2005