Re: 100% Java Subversion client 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).

I thought of move, rename, add, delete as separate commands (which can
be added step-by-step). Does subversion watch for file-system
modifications (e.g. by renaming a file/directory in the Windows Explorer)???

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

Is there also the possibility to set an environment variable like
CVS_CLIENT_LOG in CVS? Does all subversion client-server communication
runs over a fixed socket port, so I easily can write a simple
tee-socket-proxy?

Some questions to the Java-bindings:
- How well they work with multiple threads?
- Do they provide a progress-listener interface, so one easily can
   show a progress bar in the user interface?
- Do they have listeners for the server responses (like the subversion
   pendant of 'cvs log'), so no parsing is required?
- Are different text encodings are possible?
- How well file name encodings are possible (e.g. Japanese file names)?
- Are the bindings high-level (command level) or lower-level
   (request-/response-level)?

--
Best regards,
Thomas Singer
_____________
smartcvs.com
Branko Čibej wrote:
> 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
> 
> 
> 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org