Hi Thomas,
subversion@smartcvs.com wrote:
>>> 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?
>
I am just answering for the javahl binding, which author I am.
> Some questions to the Java-bindings:
> - How well they work with multiple threads?
Other than a problem in 1.0.5, for which a fix is nominated for the next
release, it should be multithread clean.
> - Do they provide a progress-listener interface, so one easily can
> show a progress bar in the user interface?
There is a notification interface, which could be use to show a progress
bar.
> - Do they have listeners for the server responses (like the subversion
> pendant of 'cvs log'), so no parsing is required?
All returned information like log and status is available via java
object, so that no parsing is required.
> - Are different text encodings are possible?
Not really, Everything is just UTF, since thats how subversion and java
handles texts.
> - How well file name encodings are possible (e.g. Japanese file names)?
See above. I have never tried japanese file names, but I see no reason
why that should not work.
> - Are the bindings high-level (command level) or lower-level
> (request-/response-level)?
This is a high level interface.
Only implementing the svn:// protocol will make the library much less
usefull, since many public svn repositories are only accessable via
http:// and https://
> --
> Best regards,
> Thomas Singer
> _____________
> smartcvs.com
>
Best Regards,
Patrick Mayweg
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 25 17:02:02 2004