Hello Brock,
> It would be much easier if you only wanted to support the
> svnserve or webdav protocols as these are just transport
> protocols, but quite a few people use the 'file'.
I would say it would be easier, but still could take a lot of time to
implement complete http(s), svn and tunnels (svn+ssh) support, plus a
working copy support that is compatible with 1.2.x and 1.4.x wc formats.
And, as Mark noticed, efforts to maintain library should be taken in
account. The licensing scheme JavaSVN uses (commercial licensing for closed
source projects) allows to fund JavaSVN maintainaince and development.
Considering demand in pure Java Subversion library and existing commercial
customers, there are quite good chances JavaSVN will be maintained and kept
up to date in the future.
On the other hand, I expect JavaSVN to be relicensed under EPL (or other
BSD-like license) sooner or later. It couldn't be relicensed right now
without adequate compensation, but it is quite possible in a few years.
Alexander Kitaev,
TMate Software,
http://tmate.org/
> -----Original Message-----
> From: Brock Janiczak [mailto:brockj@tpg.com.au]
> Sent: Thursday, July 06, 2006 2:13 PM
> To: dev@subclipse.tigris.org
> Subject: Re: [Subclipse-dev] Submitting Subclipse as project
> to Eclipse.org
>
> Thomas Hallgren wrote:
> > Brock Janiczak wrote:
> >> Eclipse already uses natives for things other than SWT,
> for instance
> >> the filesystem plugin.
> >
> > The filesystem platform native plugin is optional and only
> needed when
> > you want automatic workspace refresh (since Java has no API
> for file
> > system events ... yet). I assure you, we really do create platform
> > agnostic distributions based on Eclipse.
> I was referring to the new filesystem plugin
> (org.eclipse.core.filesystem) added in 3.2 that provides
> access to file attributes (including execute bit) and is used
> by the Eclipse Filesystem
> (EFS)
> My point was that you can create platform agnostic
> distributions when you have natives, so long as you provide
> natives for all platforms, or a fallback java solution. We
> *can* provide natives for all platforms, but they won't
> always work due to their reliance on third party natives.
> >
> >> The short answer is: "very hard". You would need to
> support the SVN
> >> working copy format (not so hard) as well as the FSFS
> repository type
> >> (really hard). Maintenance would be a major issue. The
> Subversion
> >> team does a great job of adding new features, which is great for
> >> users, but not so great if you have to maintain your own client
> >> implementation.
> >
> > OK, my mistake then. I though the JavaHL and JavaSVN where API's on
> > top of a protocol only and that only the server side was concerned
> > with FSFS. Just out of curiosity, why is the client
> concerned with that?
> There you go. Alex answered for me :)
>
> It would be much easier if you only wanted to support the
> svnserve or webdav protocols as these are just transport
> protocols, but quite a few people use the 'file'.
>
> ---------------------------------------------------------------------
> 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 12:33:08 2006