Re: 100% Java Subversion client library

Hi David,

> sure, but you would lose functionality, and shut off a section of users. Both myself and my company have 'only' supported HTTP-based access.

Well, for a first test, I guess svn:// would be enough, assuming that
WebDAV/DeltaV is just another level on top of it which should be
possible to implement using existing Java libraries (if necessary at
some time).

> significantly more difficult, since subversion's working copy
> tracks all the original file versions locally between commits,
> and tracks moves and copies.

Could you please elaborate a little bit.

> The edge cases when someone both
> moves and modifies a file in one revision are.. not pretty :)

I don't have any detailled experience with subversion, so don't whack me
if I'm wrong.

I guess, you run a command "subversion rename <old-file-name>
<new-file-name>" and subversion recordes this change somewhere. When
committing, it compares the <old-file-name>'s backup copy with
<new-file-name>'s content and detects, that the file is modified and
sends some different requests...

> I know I would personally stick with JNI, and be happy
> focusing on code which provided new functionality :).

As already said, some cool features in SmartCVS only were possible
because the client functionality was available as a Java-library I could
turn up-side-down.

Please compare the subverson situation with the CVS situation. If you
had to write a CVS client in Java, would you rather use a Java-library
for the CVS functionality you can modify or would you use the native
Subversion executable/library as a black-box and take the risk, that you
have to answer your customers "Sorry, you first need to find a decent
compiler to compile the Java-to-native-bindings on your machine"?

--
Best regards,
Thomas Singer
_____________
smartcvs.com
David Waite wrote:
> On Jun 25, 2004, at 7:48 AM, 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?
> 
> 
> sure, but you would lose functionality, and shut off a section of users. 
> Both myself and my company have 'only' supported HTTP-based access.
> 
>>
>>>    * <>remplement a svnserve-protocol layer
>>>    * <>reimplement the working-copy management library
>>
>>
>> Is this comparable with writing a CVS client?
> 
> 
> significantly more difficult, since subversion's working copy tracks all 
> the original file versions locally between commits, and tracks moves and 
> copies. The edge cases when someone both moves and modifies a file in 
> one revision are.. not pretty :)
> 
>>> 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.
> 
> 
> Just to clarify, you can add file:// now, but it would probably not be 
> interoperable with other file clients at the same time over the same 
> database:
> 
> http://www.sleepycat.com/products/je.shtml
> 
> I do not know how compatible it is with existing BDB installations; I 
> imagine 'not very', as the BDB format is platform-specific.
> 
> <snip>
> 
>>> 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).
> 
> 
> Part of me says go for it - it will be an excellent learning experience, 
> a validation of subversion's design, and could expose some interesting 
> edge cases which were missed over the evolution to 1.0. But you already 
> have decided to cut features out for your users (http and local 
> repository access), and its not clear to me what sort of functionality 
> you would gain. I know I would personally stick with JNI, and be happy 
> focusing on code which provided new functionality :).
> 
> -David Waite
> 
> 
> 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org