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).
This assumption is incorrect. WebDAV and svnserve protocols are not
layered on top of one another. They couldn't be, since WebDAV is an HTTP
extension (and therefore stateless), while svnserve is a custom,
stateful protocol. They only share a top-leve, repository-access library.
> 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"?
Judging by your responses, I think you're taking a very naive approach
to this Java port of Subversion. First of all, Subversion is a _lot_
more complex than CVS (2 repository back-ends vs. 1, 2 network access
protocols vs. 1, transactions, directory versioning, etc. etc.). Second,
I don't see why you'd want customers to recompile, let alone modify, the
core Subversion libraries.
All in all, I suggest you take time to learn about the Subversion
architecture and design (there are design docs in our repository, and
there's the Subversion book which describes some of that). Right now I
think you're working on assumptions that seem to be mostly wrong -- the
first one being that SVN and CVS are comparable. They're not, except in
terms of the usage model, which is the least of your worries.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 25 18:30:50 2004