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
Received on Fri Jun 25 19:33:44 2004