Hello Thomas,
Finally, I do not understand what we're talking about :)
There is a pure Java Subversion client library, JavaSVN. It already supports
remote (http, svn, etc.) and local (file) access to Subversion repository.
Support for "file" protocol is important, but not the major part of JavaSVN.
It took significantly more time and efforts to implement working copy
support and client features related to working copy management, rather than
"file" protocol implementation.
So the anwer to your question on how complex it would be to create a "clean
room" pure Java subversion client implementation is that it could take a lot
of time even without local repository access support. And it is not very
intersting or challenging task.
Alexander Kitaev.
> -----Original Message-----
> From: Thomas Hallgren [mailto:thomas@tada.se]
> Sent: Thursday, July 06, 2006 3:39 PM
> To: dev@subclipse.tigris.org
> Subject: Re: [Subclipse-dev] Submitting Subclipse as project
> to Eclipse.org
>
> Alexander Kitaev wrote:
> > Hello Thomas,
> >
> >> OK, so you have a solution where the server is more or
> less embedded
> >> in the client. But since Subversion is so nicely layered,
> wouldn't it
> >> be simple to just require a server installation for the
> cases where
> >> you want to support local access? Seems odd to me that a
> pure client
> >> cannot be implemented although a lot of effort has gone
> into making
> >> the whole thing client/server and layered.
> > Initially JavaSVN didn't included direct fsfs repository access
> > support and users were suggested to install server
> (svnserve) or use
> > svn+ssh to access repository on the local computer.
> However, there are
> > applications other then Subclipse that interact with Subversion
> > repositories and it is much more usable for those applications to
> > access repository directly. Also direct access could be
> faster comparing to access through the server.
> >
> I'm sure there are reasons for direct local access and
> apparently there are good solutions that deal with it. What
> surprises me is that there is no pure client and that the
> local access aspect apparently prevents the creation of one.
> If I had a choice between a pure client, perhaps not all that
> optimal for local access and the drawbacks of multiple native
> libraries, I'd choose the former anytime. That is probably
> true for the majority of users who never use the "file"
> protocol. Now there is no such choice unless you're happy
> with GPL or paying for it.
>
> > I agree with you that from the end-user point of view
> "file" protocol
> > support is not really important, but for some projects it
> could be critical.
>
> I'm not arguing the importance of the protocol as such. I'm
> just saying that it would be reasonable to install server
> functionality should you need it. A pure client that
> discovers that no server is present locally could simply
> refuse to serve requests using the "file"
> protocol. If a server was found, perhaps it could connect to
> it using a more optimal protocol?
>
> > Also it opens a way to pure Java Subversion server implementation.
> >
> That would be cool or course but to me, a pure Java (EPL or
> BSD licensed) client is far more important.
>
> Regards,
> Thomas Hallgren
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: dev-help@subclipse.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Thu Jul 6 13:52:48 2006