subversion@smartcvs.com wrote:
> Hi Branko and Patrick,
>
> Please see my comments below.
>
>> * remplement a WebDAV/DeltaV client layer<>
>
> Do I understand it correctly, this WebDAV/DeltaV is not necessary when
> using the svn:// protocol?
Yes, that's correct. WebDAV is used for the http[s]:// access method.
>> * <>remplement a svnserve-protocol layer
>
This is for the svn:// access method.
>> * <>reimplement the working-copy management library
>
> Is this comparable with writing a CVS client?
No, it's a lot more complicated because Subversion tracks directory
changes (move, rename, add, delete).
>> before you can even start thinking about an actual client. If you
>> want file:// access in "100% java", you'll have to rewrite all of
>> Berkeley DB -- an impossible task, IMHO.
>
> We do not plan to add support for the file:// protocol, "just" socket
> communication between client and server.
>
>> The Subversion source is the best reference. The APIs are very well
>> documented, and the command-line client serves as an example of how
>> to use them.
>
> I don't need to know (at least I hope so) how something is
> implemented. It would be enough to know, how it _should_ work.
Exactly. The APIs are documented, and the command-line client shows how
to use them.
>> Why would you want to do that? All our protocols are documented, some
>> in RFCs.
>
> Even the CVS protocol is documented somehow, but nobody is able to
> write a client based on this documentation (don't know yet about the
> quality of the subversion protocol documentation).
Well, you can assume that from our point of view, what CVS has isn't
"documentation": :-)
> For me it helped a lot to study the requests sent to the CVS server
> and the responses received from the CVS server. I had the hope, that
> something like this would make it easier for me to get a grip on
> Subversion.
As I said, you can use etherreal to trace at the socket level.
>> All that said, I think you're making a big mistake trying to rewrite
>> Subversion in Java. You'd be duplicating years of effort, for no real
>> gain that I can see. You'd do much better to use our existing Java
>> bindings.
>
> I did not said, that we finally will do it. I just want to make a
> simple spike to see how hard it is before making the decision.
>
> From my experience I can say, Java-to-native bindings tend to break
> silently. Bugs don't show up at compile-time and the bindings are hard
> to unit-test (compared to well-designed Java code).
I wouldn't know about that, but surely Java bindings can be made stable.
Adding regression tests for our bindings is a good idea anyway, and the
time would be much better spent than rewriting the world in Java.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 25 15:59:06 2004