[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: 100% Java Subversion client library
From:       David Waite <mass () akuma ! org>
Date:       2004-06-25 17:25:56
Message-ID: B7FCAEBA-C6CC-11D8-AD0A-000A95C89D86 () akuma ! org
[Download RAW message or body]


On Jun 25, 2004, at 8:54 AM, subversion@smartcvs.com wrote:

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

Very true - this is how the C code was developed, after all - the 
different repository access mechanisms are plug-ins. However, at least 
for the short term, you are doing a large amount of work to deliver 
less functionality vs. JNI, and will have to deal with supporting new 
features in subversion as they arrive.

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

You can have moves and copies as well as modifications in the local 
working copy, the working copy directory (.svn) has to maintain 
information to track this. Behavior for chained events for one commit, 
like:

modify file
copy same file
modify #2 version
delete #1 version
move #2 to have #1 filename

can get really, really hairy. You would have the benefit however of 
being able to port the working copy tests from the subversion 
distribution.

>
>> 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"?

That is different however, as CVS has no library interface, and thus 
cannot have JNI bindings - the only way to use the CVS packages from a 
java program is executing the program and parsing its output.

-David Waite


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

[prev in list] [next in list] [prev in thread] [next in thread]