Branko Čibej wrote:
> email@example.com wrote:
>> 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
> -- Brane
As the author of one of the java bindings of subversion, I can only
second Brane's comments. I have also thought about implement a pure java
client first, but the amount code, which would have ported to java, was
to much. Even with the good documentation in the code, the effort was
not worth it.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Jun 25 14:54:03 2004