Re: 100% Java Subversion client library

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?

> * <>remplement a svnserve-protocol layer
> * <>reimplement the working-copy management library

Is this comparable with writing a CVS client?

> 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.

> 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). 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.

> 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).

--
Best regards,
Thomas Singer
_____________
smartcvs.com
Branko Čibej wrote:
> subversion@smartcvs.com wrote:
> 
>> Hi,
>>
>> my name is Thomas Singer and I'm the author of SmartCVS. Since a 
>> couple of SmartCVS users asked me about a "SmartSVN", I need to 
>> estimate the required effort. A lot of features we have implemented in 
>> SmartCVS only were possible, because the used JavaCVS-library 
>> (javacvs.netbeans.org) was written in 100% Java. Hence we are thinking 
>> about writing a 100% Java (Open Source) subversion client library 
>> instead of using DLLs or command line executables.
> 
> 
> You're not the first person to ask about this, and you're in for very, 
> very big trouble, even if you don't try to implement the file:// access 
> method. You'll have to do at least the following:
> 
>    * remplement a WebDAV/DeltaV client layer<>
>    * <>remplement a svnserve-protocol layer
>    * <>reimplement the working-copy management library
> 
> 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.
> 
>> My questions:
>> - Are there any existing projects with the same goal?
> 
> 
> Not as far as I know.
> 
>> - Where can I find design documents, which give a developers view of 
>> the tasks a subversion client needs to implement?
> 
> 
> 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.
> 
>> - How to capture the data send between the command line subversion 
>> client and the server?
> 
> 
> Why would you want to do that? All our protocols are documented, some in 
> RFCs. Of course, you can always do an etherreal trace, which is what we 
> do for debugging if worse comes to worst.
> 
>> Thanks in advance for your feed-back and co-operation.
> 
> 
> 
> 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.
> 
> -- Brane
> 
> 
> ---------------------------------------------------------------------
> 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